On 5/18/22 02:41, Richard Biener wrote:
On Tue, May 17, 2022 at 8:41 PM Andrew MacLeod via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
This patch implements side effects of the second operand of a shift
operation.
given A >> B or A << B, the range of B is restricted to [0, PRECISION_A).
Fortran is currently more permissive than this, allowing the range to be
[0, PRECISION_A], so this si the value we currently default to in this
patch. If the fortran front end were adjusted, we could adjust the end
point.
This currently bootstraps with no regressions on x86_64-pc-linux-gnu.
Is this sufficient, or should I also be checking some other flags which
may allow other values outside this range to be valid?
I think the "undefined behavior" side-effects are dangerous since
I know of no code that makes sure to clamp the shift argument when
hoisting it. sanitizing shifts will also not help to discover such latent
issues since sanitizing is happening early and it will most definitely
avoid the hoisting itself.
As to that we _definitely_ want a way to disable this [assumption
that the shift operand is in-range] if we make that assumption
even on IL state after optimizations.
Candidates to look for are invariant motion, ifcombine,
partial PRE, PRE in general (we possibly hoist such expressions
across function calls that might terminate the program normally).
That is, what prevents
if (n > 32)
abort ();
x = i << n;
to be transformed to
x = i << n;
if (n > 32)
abort ();
? Yes, that's probably a latent issue in some sense but you would
now optimize the if (n > 32) abort () away while previously x would
have an undetermined value but we'd still abort.
Do you have some statistics on how this particular side-effect
improves code generation?
Richard.
None whatsoever... just a PR requesting it that has been open for 15
years :-)
If we don't want to do this optimization, then we should kill the PR. I
can also attach the path to the PR than if anyone cares enough about
this functionality, they could pursue the other effects...
Andrew
