Check whether rustc eliminates arithmetic from const zero values
unzvfu opened this issue · comments
In a comment on #68, it was noted that the value of the constant ORDER[2] for the Tweedle* curves is zero, and so the compiler should simplify/eliminate arithmetic involving that value. This should be verified over at https://godbolt.org.
- Compiler version - 1.48.0 (same results were using nightly version);
- Optimization level - 3 (same as in project, in cargo.toml);
- Examples 1,2 - if we don't use cycle, we achieve an optimization, function immediately return either 0 or desired value;
- Example 3. - a small optimization is achieved because of large number of constants.
- Example 4 - better optimization because of lack of cycle.
Thanks @MrNeither! I agree that this evidence is convincing. I have also verified that the appropriate assembly is generated when ORDER is accessed in a loop with index j%4 where the loop is an explicit for loop with upper bound a const generic parameter. I think that scenario should be the most difficult one we'll throw at the compiler, so I'm satisfied this issue can be closed.
On a related note, with the Tweedle curves the top word of ORDER is equal to 0x4000000000000000; I have also verified that the compiler emits the appropriate shift instead of a multiplication in that case.