FR: add --aggresive-constant-arithmetic flag

[wrightwriter]

Input:

out vec4 fragColor;
uniform float t;
void main() {
  float x = t;
  fragColor = vec4(x + 1. + 1. + 1.);
}

Output:

out vec4 f;
uniform float m;
void main(){
    f=vec4(m+1.+1.+1.);
}

Input:

out vec4 fragColor;
uniform float t;
void main() {
  float x = 999.;
  fragColor = vec4(x + 1. + 1. + 1.);
}

Output:

out vec4 f;
uniform float m;
void main(){
    f=vec4(1002);
}

[eldritchconundrum]

Surprisingly, there's a reason for this.

1. + 1. + 1. + x means ((1. + 1.) + 1.) + x, it can always safely be changed into 3. + x

But x + 1. + 1. + 1. means ((x + 1.) + 1.) + 1.. Rewriting it as x + 3. actually changes the order of evaluation, and due to floating-point subtleties, this can in some cases change the result.
So, it introduces the additional difficulty of how to be sure that this minification is not harmful.

[wrightwriter]

Fair point, but maybe we can have this as a flag.

[laurentlb]

The main reason is because the parse tree is not the same and we don't detect this case (it's a bit more complicated to detect).

For a workaround, use parens:

vec4(x + (1. + 1. + 1.));

I'm not much concerned by float precision with additions, here.

[therontarigo]

Good point that it is not so easy to implement this optimization, but on the other hand it is fair to have it if possible at theoretical loss of precision since driver shader compilers do such transformations anyway.

[eldritchconundrum]

It doesn't seem that complicated to detect. This should be similar to multiplication order swapping, which we already do.

For multiplication it was important to not change the order when more than one matrix type is involved. But additions should be commutative whatever the types of the operands are (scalar, vector, matrices). No type information seem needed.