Re: Miscompilation of remainder expressions

["Richard Guenther" <richard dot guenther at gmail dot com>]

On 1/19/07, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Thu, Jan 18, 2007 at 05:36:23PM -0500, Robert Dewar wrote:
> > Morten Welinder wrote:
> > >>For sure a/b is undefined
> > >
> > >In C, it is.  In assembler it is perfectly well defined, i.e., it
> > >traps.  But how is the
> > >trap handler supposed to know the source of a given instruction?
> > >
> > >M.
> >
> > Sure it traps, but what happens when that trap occurs is of course
> > O/S dependent, there is no guarantee of the effect.
>
> We're going around in circles.  Everything has been said. What if we put
> together a Wiki page with the problem and possible solutions, as in
>
> a) do nothing, no big deal.  This is what happens if no one contributes
>    code in any case.
>
> b) add a flag to generate code to compute something like
>     divisor == -1 ? 0 : rem(dividend,divisor)
>    or
>     divisor == rem(dividend,abs(divisor))
>    in an efficient way (cmov to avoid busting the pipeline)

Note that cmov is not the right thing to use here (at least on
ia32 and x86_64) as it is more expensive than compare and jump
if not the probability of taking either way are the same (which I
would not expect here, as divisor == -1 should be nearly never
the case).

That said, a transformation on the tree level would make it possible
for VRP to optimize away the special casing.

Richard.