On Thu, Feb 03, 2022 at 10:06:42AM +0100, Eric Botcazou wrote:
> > Well, yes, we have to fix it. I will share my thoughts when coming
> > along the bugreport.
>
> IMO we should simply scrap it, as it does not serve any useful purpose,
> breaks
> a very ancient and useful idiom and also introduces an artificial discrepancy
> between 1/X and 2/X for example.
That doesn't make sense.
The optimization can be useful, it doesn't have to be for user written
y = 1 / x; but can appear through inlining or some other optimizations, e.g.
jump threading and suddenly we have constant 1 in some bb, if it a never
executed at runtime block, it will be likely shorter because of the
optimization, if it is not, then it will be cheaper.
And, this is definitely not the first optimization that assumes undefined
behavior in integer division should not happen, lots of other optimizations
do the same thing.
E.g. consider
unsigned
foo (unsigned x, unsigned y)
{
if (x >= 2)
return 0;
if (x == 1)
y += 4;
return y / x;
}
Here the ranger optimizes away the division, in GCC11 in vrp1 pass, in
GCC12 in evrp pass already. Even in match.pd I vaguely remember one or two
optimizations where it also relied on division by zero being undefined.
Jakub
