* HP-UX IA64 Patch to fix earlier patch
@ 2002-11-06 14:01 Steve Ellcey
2002-11-14 10:37 ` Jim Wilson
0 siblings, 1 reply; 5+ messages in thread
From: Steve Ellcey @ 2002-11-06 14:01 UTC (permalink / raw)
To: gcc-patches
I sent a patch a while back to change argument passing on HP-UX IA64 and
make it match what the HP compiler does
(http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01782.html).
Somehow I managed to screw up the patch and the change wound up in
store_bit_field instead of extract_bit_field. This change undoes that
earlier patch and puts the extra test where it should be.
Neither the earlier patch nor this one should affect any other platform
because FUNCTION_ARG_REG_LITTLE_ENDIAN is set to 0 in defaults.h so it
has no effect on the test except for HP-UX IA64.
2002-11-06 Steve Ellcey <sje@cup.hp.com>
* expmed.c (store_bit_field): Remove use of
FUNCTION_ARG_REG_LITTLE_ENDIAN.
(extract_bit_field): Add use of
FUNCTION_ARG_REG_LITTLE_ENDIAN.
*** gcc.orig/gcc/expmed.c Wed Nov 6 13:52:53 2002
--- gcc/gcc/expmed.c Wed Nov 6 13:53:24 2002
*************** store_bit_field (str_rtx, bitsize, bitnu
*** 404,410 ****
But as we have it, it counts within whatever size OP0 now has.
On a bigendian machine, these are not the same, so convert. */
if (BYTES_BIG_ENDIAN
- && !FUNCTION_ARG_REG_LITTLE_ENDIAN
&& GET_CODE (op0) != MEM
&& unit > GET_MODE_BITSIZE (GET_MODE (op0)))
bitpos += unit - GET_MODE_BITSIZE (GET_MODE (op0));
--- 404,409 ----
*************** extract_bit_field (str_rtx, bitsize, bit
*** 1089,1094 ****
--- 1088,1094 ----
But as we have it, it counts within whatever size OP0 now has.
On a bigendian machine, these are not the same, so convert. */
if (BYTES_BIG_ENDIAN
+ && !FUNCTION_ARG_REG_LITTLE_ENDIAN
&& GET_CODE (op0) != MEM
&& unit > GET_MODE_BITSIZE (GET_MODE (op0)))
bitpos += unit - GET_MODE_BITSIZE (GET_MODE (op0));
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HP-UX IA64 Patch to fix earlier patch
2002-11-06 14:01 HP-UX IA64 Patch to fix earlier patch Steve Ellcey
@ 2002-11-14 10:37 ` Jim Wilson
0 siblings, 0 replies; 5+ messages in thread
From: Jim Wilson @ 2002-11-14 10:37 UTC (permalink / raw)
To: sje; +Cc: gcc-patches
Perhaps you should be including testcases for these patches. Your last
patch makes it very clear that you wanted to modify store_bit_field, and
now your claim that you meant to modify extract_bit_field all along is not
very convincing.
It would also help if you gave a clearer explanation of what the patch is
doing.
FUNCTION_ARG_REG_LITTLE_ENDIAN according to the documentation is intended
to handle structure argument passing conventions. Using it in either
store_bit_field or extract_bit_field doesn't seem to make much sense, since
they don't have anything to do with calling conventions. Perhaps this is
necessary when a function argument register is passed to extract_bit_field
and/or store_bit_field. However, your change affects every bit field
extract/store, regardless of whether it is a function arg reg, so that doesn't
seem right. Perhaps you need to modify calling convention code to change the
way it is calling extract/store bit field, or perhaps pass another argument
so that it can behave differently when passed a function arg reg.
Alternatively, I suspect you could get rid of FUNCTION_ARG_REG_LITTLE_ENDIAN
if you modified the IA-64 FUNCTION_ARG macro to return a PARALLEL instead
of a REG for your problematic cases. This causes the calling convention
support code to use emit_group_load/store in expr.c, and these routines
will left-justify small structures in registers on big-endian targets, which
is probably the behaviour you want.
Jim
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HP-UX IA64 Patch to fix earlier patch
2002-11-15 15:48 ` Steve Ellcey
2002-11-15 17:00 ` John David Anglin
@ 2002-11-15 17:38 ` Jim Wilson
1 sibling, 0 replies; 5+ messages in thread
From: Jim Wilson @ 2002-11-15 17:38 UTC (permalink / raw)
To: Steve Ellcey; +Cc: dave, gcc-patches
>I'll give this a try. Do you know if this behavour keys off of
>WORDS_BIG_ENDIAN, BYTES_BIG_ENDIAN, or BITS_BIG_ENDIAN?
BYTES_BIG_ENDIAN
Few parts of the compiler use BITS_BIG_ENDIAN. I think it is only used for
interpreting the fields of a {zero,sign}_extract operator. Usually, you can
make an arbitrary choice for BITS_BIG_ENDIAN, and it will work fine. Usually,
there is no point in changing BITS_BIG_ENDIAN when the byte endianness changes.
Jim
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HP-UX IA64 Patch to fix earlier patch
2002-11-15 15:48 ` Steve Ellcey
@ 2002-11-15 17:00 ` John David Anglin
2002-11-15 17:38 ` Jim Wilson
1 sibling, 0 replies; 5+ messages in thread
From: John David Anglin @ 2002-11-15 17:00 UTC (permalink / raw)
To: Steve Ellcey; +Cc: wilson, gcc-patches
> > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
> >
> > I agree with Jim here. Not too long ago, I used this technique to avoid
> > defining FUNCTION_ARG_REG_LITTLE_ENDIAN on the hppa64 port. I also
> > managed to fix a long standing bug in the 32-bit port passing small
> > structs using the same technique. Jim's comment is an over simplification
> > of what really happens when a DImode value is used in a PARALLEL on
> > big-endian 32-port. You actually get right-justified data in this case.
> > See function_arg and function_arg_padding in pa.c.
>
> I'll give this a try. Do you know if this behavour keys off of
> WORDS_BIG_ENDIAN, BYTES_BIG_ENDIAN, or BITS_BIG_ENDIAN? On PA HP-UX all
> of these are 1, but on IA64 HP-UX we are setting BYTES and WORDS to 1
> and leaving BITS at 0. Setting BITS_BIG_ENDIAN to 1 was causing some
> problems that I don't recall off the top of my head.
emit_group_load and emit_group_store use extract_bit_field and
store_bit_field. They don't directly key off any of the above
but extract_bit_field and store_bit_field do.
In the 32-bit port, we had the rather unique situation where 5-8 byte
structs needed to be right-justified in the same manner as 1-4 byte
structs. Structs larger than this are left justified.
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HP-UX IA64 Patch to fix earlier patch
[not found] <200211150002.gAF021fD013288@hiauly1.hia.nrc.ca>
@ 2002-11-15 15:48 ` Steve Ellcey
2002-11-15 17:00 ` John David Anglin
2002-11-15 17:38 ` Jim Wilson
0 siblings, 2 replies; 5+ messages in thread
From: Steve Ellcey @ 2002-11-15 15:48 UTC (permalink / raw)
To: dave, wilson; +Cc: gcc-patches
> From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>
> I agree with Jim here. Not too long ago, I used this technique to avoid
> defining FUNCTION_ARG_REG_LITTLE_ENDIAN on the hppa64 port. I also
> managed to fix a long standing bug in the 32-bit port passing small
> structs using the same technique. Jim's comment is an over simplification
> of what really happens when a DImode value is used in a PARALLEL on
> big-endian 32-port. You actually get right-justified data in this case.
> See function_arg and function_arg_padding in pa.c.
I'll give this a try. Do you know if this behavour keys off of
WORDS_BIG_ENDIAN, BYTES_BIG_ENDIAN, or BITS_BIG_ENDIAN? On PA HP-UX all
of these are 1, but on IA64 HP-UX we are setting BYTES and WORDS to 1
and leaving BITS at 0. Setting BITS_BIG_ENDIAN to 1 was causing some
problems that I don't recall off the top of my head.
Steve Ellcey
sje@cup.hp.com
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2002-11-16 1:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-06 14:01 HP-UX IA64 Patch to fix earlier patch Steve Ellcey
2002-11-14 10:37 ` Jim Wilson
[not found] <200211150002.gAF021fD013288@hiauly1.hia.nrc.ca>
2002-11-15 15:48 ` Steve Ellcey
2002-11-15 17:00 ` John David Anglin
2002-11-15 17:38 ` Jim Wilson
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).