Andrew Haley wrote:
Ian Lance Taylor writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
>
> > Ian, do you believe something along the line of
> >
> > # > I mean, could not we generate the following for "%":
> > # >
> > # > rem a b :=
> > # > if abs(b) == 1
> > # > return 0
> > # > return <machine-instruction> a b
> > #
> > # On x86 processors that have conditional moves, why not do the equivalent
> > # of
> > #
> > # neg_b = -b;
> > # cmov(last result is negative,neg_b,b)
> > # __machine_rem(a,b)
> > #
> > # Then there's no disruption of the pipeline.
> >
> > is workable for the affected targets?
>
> Sure, I think the only real issue is where the code should be
> inserted.
From a performance/convenience angle, the best place to handle this is
either libc or the kernel. Either of these can quite easily fix up
the operands when a trap happens, with zero performance degradation of
existing code. I don't think there's any need for gcc to be altered
to handle this.
That only works if the operation causes a trap. On x86 this is the
case, but Andrew Pinski told me on IM that this was not the case for PPC.
David Daney
