Optimizer Arithmetic Operations Order

Users
1

For code like

 M * (x * (_e:uint(w) << (p - 1)).transmute(real(w)))

where both M and x are real(w) numbers, does the optimizer always honour the order in which the multiplications are specified?

Thanks,

2

Hi Damian,

I expect Chapel to preserve the order of the two multiplications into the generated C or LLVM code. With the caveat that I am not familiar with all the optimizations that our compiler performs.

I do not know what C or LLVM will do when they get these multiplications as their input.

Vass

3

I was going to answer similarly if nobody else did. I'm more confident than Vass that the Chapel compiler won't reorder the multiplications. I'm similarly unsure what C or LLVM will or won't do.

-Brad

4

Hi. You guys piqued my curiosity so I looked it up.
chpl --fast --no-ieee-float will pass the fast-float flag to the back-end compilers and allow the reordering. However, chpl --fast without --no-ieee-float will only go as high as -O3 and will not pass the flag that allows the back-end to reorder.

1 Like
5

I should clarify that the C standard by itself is not sufficient to guarantee the order of evaluation. It is only if an implementation claims IEEE floating-point compliance, and a reordering would affect the IEEE result, that a reordering would be disallowed.

By contrast, Fortran actually requires honoring parentheses for evaluation order.

1 Like
6

Wow. :Lots of heavy hitters responding here. Thank you one and all.

I was just checking before I do some documentation. I have code

M * (x * f)

which, when the result of that expression underflows, will only ever have a single rounding error.

There are values for x, M and f for which it can be proven that if this is reordered to be evaluated instead as

(x * M) * f

then the result of that expression will actually have two rounding errors (which I do not want obviously).

I only ever compile with --ieee-float unless I am testing.

As those 3 numbers are variables and not known at compile time, I hope the compiler is not arrogant enough to think it can reorder things.

As I would like to see Chapel honour parentheses, so I should ask how Flang demands that LLVM do the right thing by it and honour parentheses. And the Chapel compiler can complain very loudly if it thinks this will result in sub-optimal code (which might prompt me to think again at why I have a certain computation ordering). I always had the impression that the LLVM flag to honour parenthesis killed off a lot of optimizations (that should be theoretically possible even if you are honouring parentheses). I could be wrong.

7

For the purposes of my documentation which is ,my priority, I wll assume the ordering is honoured subject to --ieee-float being used at compilation Thanks