[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