HP-UX IA64 Patch to fix earlier patch

HP-UX IA64 Patch to fix earlier patch

[Steve Ellcey]

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));

Re: HP-UX IA64 Patch to fix earlier patch

[Jim Wilson]

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

Re: HP-UX IA64 Patch to fix earlier patch

[Steve Ellcey]

> 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

Re: HP-UX IA64 Patch to fix earlier patch

[John David Anglin]

> > 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)

Re: HP-UX IA64 Patch to fix earlier patch

[Jim Wilson]

>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