* Re: More 128 bit floating point stuff for PA64
@ 2002-09-06 13:25 Steve Ellcey
2002-09-06 13:51 ` Jeff Law
2002-09-06 21:02 ` John David Anglin
0 siblings, 2 replies; 6+ messages in thread
From: Steve Ellcey @ 2002-09-06 13:25 UTC (permalink / raw)
To: gcc, dave.anglin, law
I have been doing some more mix-and-match testing between the HP 64 bit
compiler and GCC and I think that the code for returning 128 bit floats
is wrong but I am not sure exactly how to fix it. I believe the problem
is in FUNCTION_VALUE (pa.h) which is:
/* On the HP-PA the value is found in register(s) 28(-29), unless
the mode is SF or DF. Then the value is returned in fr4 (32, ) */
/* This must perform the same promotions as PROMOTE_MODE, else
PROMOTE_FUNCTION_RETURN will not work correctly. */
#define FUNCTION_VALUE(VALTYPE, FUNC) \
gen_rtx_REG (((INTEGRAL_TYPE_P (VALTYPE) \
&& TYPE_PRECISION (VALTYPE) < BITS_PER_WORD) \
|| POINTER_TYPE_P (VALTYPE)) \
? word_mode : TYPE_MODE (VALTYPE), \
TREE_CODE (VALTYPE) == REAL_TYPE && !TARGET_SOFT_FLOAT ? 32 : 28)
What I want to say is that if it is REAL_TYPE but is long double (128
bits) then use register 28 instead of register 32 but I have a very hard
time parsing this macro and figuring out the right way to do that test,
can anyone give me some words of wisdom.
Steve Ellcey
sje@cup.hp.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: More 128 bit floating point stuff for PA64
2002-09-06 13:25 More 128 bit floating point stuff for PA64 Steve Ellcey
@ 2002-09-06 13:51 ` Jeff Law
2002-09-06 21:02 ` John David Anglin
1 sibling, 0 replies; 6+ messages in thread
From: Jeff Law @ 2002-09-06 13:51 UTC (permalink / raw)
To: Steve Ellcey; +Cc: gcc, dave.anglin
In message <200209062024.NAA05869@hpsje.cup.hp.com>, Steve Ellcey writes:
>I have been doing some more mix-and-match testing between the HP 64 bit
>compiler and GCC and I think that the code for returning 128 bit floats
>is wrong but I am not sure exactly how to fix it. I believe the problem
>is in FUNCTION_VALUE (pa.h) which is:
>
>
>/* On the HP-PA the value is found in register(s) 28(-29), unless
> the mode is SF or DF. Then the value is returned in fr4 (32, ) */
>
>/* This must perform the same promotions as PROMOTE_MODE, else
> PROMOTE_FUNCTION_RETURN will not work correctly. */
>#define FUNCTION_VALUE(VALTYPE, FUNC) \
> gen_rtx_REG (((INTEGRAL_TYPE_P (VALTYPE) \
> && TYPE_PRECISION (VALTYPE) < BITS_PER_WORD) \
> || POINTER_TYPE_P (VALTYPE)) \
> ? word_mode : TYPE_MODE (VALTYPE), \
> TREE_CODE (VALTYPE) == REAL_TYPE && !TARGET_SOFT_FLOAT ? 32 :
>28)
>
>What I want to say is that if it is REAL_TYPE but is long double (128
>bits) then use register 28 instead of register 32 but I have a very hard
>time parsing this macro and figuring out the right way to do that test,
>can anyone give me some words of wisdom.
Change from an ugly macro into a real function call. Instead of using
horrid ternary operators, use if-else.
Basically rewrite it to be readable/sensible. It's certainly not performance
critical.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: More 128 bit floating point stuff for PA64
2002-09-06 13:25 More 128 bit floating point stuff for PA64 Steve Ellcey
2002-09-06 13:51 ` Jeff Law
@ 2002-09-06 21:02 ` John David Anglin
2002-09-07 13:35 ` John David Anglin
1 sibling, 1 reply; 6+ messages in thread
From: John David Anglin @ 2002-09-06 21:02 UTC (permalink / raw)
To: Steve Ellcey; +Cc: gcc, dave.anglin, law
> TREE_CODE (VALTYPE) == REAL_TYPE && !TARGET_SOFT_FLOAT ? 32 :
> 28)
Just add "&& GET_MODE_BITSIZE (TYPE_MODE (VALTYPE)) <= BITS_PER_WORD" after
the REAL_TYPE check. Register 32 then will only be selected for floats
and doubles.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: More 128 bit floating point stuff for PA64
2002-09-06 21:02 ` John David Anglin
@ 2002-09-07 13:35 ` John David Anglin
0 siblings, 0 replies; 6+ messages in thread
From: John David Anglin @ 2002-09-07 13:35 UTC (permalink / raw)
To: John David Anglin; +Cc: sje, gcc, dave.anglin, law
> > TREE_CODE (VALTYPE) == REAL_TYPE && !TARGET_SOFT_FLOAT ? 32
> :
> > 28)
>
> Just add "&& GET_MODE_BITSIZE (TYPE_MODE (VALTYPE)) <= BITS_PER_WORD" after
> the REAL_TYPE check. Register 32 then will only be selected for floats
> and doubles.
I am wondering about the use of TYPE_PRECISION in this macro. The are
a couple of long double failures in the v3 suite on hppa-linux.
Long doubles are 64 bits on this port at the moment. The failures may be
related to how we pass or return short long doubles.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: More 128 bit floating point stuff for PA64
2002-09-09 13:15 Steve Ellcey
@ 2002-09-09 13:49 ` John David Anglin
0 siblings, 0 replies; 6+ messages in thread
From: John David Anglin @ 2002-09-09 13:49 UTC (permalink / raw)
To: Steve Ellcey; +Cc: gcc, law
> I think this causes problems on PA32 because BITS_PER_WORD is 32 (I
> think) and this will put doubles into regular registers instead of the
> floating point register. I am going to try checking MAX_BITS_PER_WORD
> instead of BITS_PER_WORD as the test.
Yes, I just changed the value to 64. Another possibility is to check
for TFmode. I still haven't got a chance to look at why there are a
couple of long double failures in the v3 suite.
I am fairly close to a patch for passing structures. The 32-bit
port now has less than ten fails on hppa-linux in the C suite. I
need to do more testing on the 64-bit port and 32-bit hpux. The
current justification on the 64-bit port is wrong, as you know.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: More 128 bit floating point stuff for PA64
@ 2002-09-09 13:15 Steve Ellcey
2002-09-09 13:49 ` John David Anglin
0 siblings, 1 reply; 6+ messages in thread
From: Steve Ellcey @ 2002-09-09 13:15 UTC (permalink / raw)
To: dave; +Cc: gcc, law
> > Just add "&& GET_MODE_BITSIZE (TYPE_MODE (VALTYPE)) <= BITS_PER_WORD" after
> > the REAL_TYPE check. Register 32 then will only be selected for floats
> > and doubles.
>
> I am wondering about the use of TYPE_PRECISION in this macro. The are
> a couple of long double failures in the v3 suite on hppa-linux.
> Long doubles are 64 bits on this port at the moment. The failures may be
> related to how we pass or return short long doubles.
I think this causes problems on PA32 because BITS_PER_WORD is 32 (I
think) and this will put doubles into regular registers instead of the
floating point register. I am going to try checking MAX_BITS_PER_WORD
instead of BITS_PER_WORD as the test.
Steve Ellcey
sje@cup.hp.com
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-09-09 20:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-09-06 13:25 More 128 bit floating point stuff for PA64 Steve Ellcey
2002-09-06 13:51 ` Jeff Law
2002-09-06 21:02 ` John David Anglin
2002-09-07 13:35 ` John David Anglin
2002-09-09 13:15 Steve Ellcey
2002-09-09 13:49 ` John David Anglin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).