On Thu, 3 Feb 2022, Jakub Jelinek wrote:
> 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.
Yes, we definitely have multiple of those cases. I do think
preserving "an idiom", for example literal 0/0 or all x/0 might be
worth considering. But I also think we have to sort out different
language standards requirements vs. the middle-end and whos
responsible for making sure we adhere here.
That said, for GCC 12 we can take shortcuts and one option is of
course to revert (but we don't have to rush).
oh, and even GCC 4.3 optimizes
int main()
{
volatile int tem = 0/0;
}
to just
movl $0, -4(%rsp)
even with -fnon-call-exceptions -fexceptions.
Richard.
