[PATCH] Support signbit, signbitf and signbitl as GCC builtins (take2)

Roger Sayle roger@eyesopen.com
Thu Feb 5 01:24:00 GMT 2004


On Thu, 5 Feb 2004, Ulrich Weigand wrote:
> Roger Sayle wrote:
>
> >        * builtins.c (expand_builtin_signbit): New function to RTL expand
> >        calls to signbit, signbitf and signbitl as inline intrinsics.
>
> This appears to be broken on s390x (64-bit big endian target).  The new
> builtins-32.c test case fails because it tests the high-order bit of
> the *low* order SImode half of the DFmode value, instead of the high-order
> bit of the high-order half.
>
> This is caused by an -in my understanding- invalid use of gen_highpart.
> That routine works correctly only if the high part will after reload
> reside within one register of a multi-word value, but not if the value
> will occupy the upper half of single-word value.
>
> You generate a (subreg:SI (reg:DF ...) 0), which violates this constraint
> on 64-bit big endian targets; when confronted with this subreg, reload
> silently generates incorrect code.


Perhaps this is a misunderstanding on my part.  My understanding is that
the SUBREG rtx can potentially be used to extract any suitable aligned
consecutive range of bits, as represented in one mode, from a larger/wider
mode.

For example, (subreg:QI (reg:DF ...) 0) and (subreg:QI (reg:DF ...) 5)
are perfectly valid ways of retrieving/reinterpreting parts of an FP
register.  My belief was/is that reload was supposed to spill the register
to memory if the neccesary outermode & offset can't be accessed directly.

I don't believe that the semantics of SUBREG are supposed to be affected
by register allocation or where/how the values end up being stored on a
specific target.  All that is relevant are the "endianness" target macros
which are required to caculate the offset reg.

Hence, on s390/s390x, (subreg:SI (reg:DF ...) 0) should be the upper four
bytes of the 8 byte double and (subreg:SI (reg:DF ...) 4) should be the
lower four bytes.


Of course, I may be very mistaken.  If this isn't the case, then I agree
my patch may be incorrect.  Can you provide more details of how the
generated code is incorrect?

Roger
--



More information about the Gcc-patches mailing list