On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker <ma.uec...@gmail.com>
wrote:
>
>Hi Richard,
>
>I have a question regarding reodering of volatile
>accesses and trapping operations. My initial
>assumption (and hope) was that compilers take
>care to avoid creating traps that are incorrectly
>ordered relative to observable behavior.
>
>I had trouble finding examples, and my cursory
>glace at the code seemed to confirm that GCC
>carefully avoids this. But then someone showed
>me this example, where this can happen in GCC:
>
>
>volatile int x;
>
>int foo(int a, int b, _Bool store_to_x)
>{
> if (!store_to_x)
> return a / b;
> x = b;
> return a / b;
>}
>
>
>https://godbolt.org/z/vq3r8vjxr
>
>In this example a division is hoisted
>before the volatile store. (the division
>by zero which could trap is UB, of course).
>
>As Martin Sebor pointed out this is done
>as part of redundancy elimination
>in tree-ssa-pre.c and that this might
>simply be an oversight (and could then be
>fixed with a small change).
>
>Could you clarify whether such reordering
>is intentional and could be exploited in
>general also in other optimizations or
>confirm that this is an oversight that
>affects only this specific case?
>
>If this is intentional, are there examples
>where this is important for optimization?
In general there is no data flow information that prevents traps from being
reordered with respect to volatile accesses. The specific case could be easily
mitigated in PRE. Another case would be
A = c / d;
X = 1;
If (use_a)
Bar (a);
Where we'd sink a across x into the guarded Bb I suspect.
(sorry for the odd formatting, writing this on a mobile device).
Richard.
>
>Martin
>
>
>
>
>
>
