MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[Eric Botcazou]

Hi,

The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK 
macro with this comment:

/* This needs to be set to force structure arguments with a single
   integer field to be treated as structures and not as the type of
   their field.  Without this a structure with a single char will be
   returned just like a char variable, instead of being returned at the
   top of the register as specified for big-endian IA64.  */

#define MEMBER_TYPE_FORCES_BLK(FIELD, MODE) \
  (!FLOAT_MODE_P (MODE) || (MODE) == TFmode)

That's problematic for Ada because record types with BLKmode are far less easy 
to manipulate (in particular to pack in containing records) than record types 
with integer modes.

It seems to me that it's an implementation bias that can be eliminated.  
Firstly, SPARC64 has the same set of constraints and doesn't define 
MEMBER_TYPE_FORCES_BLK.  Secondly, ia64_function_value reads:

  else
    {
      if (BYTES_BIG_ENDIAN
	  && (mode == BLKmode || (valtype && AGGREGATE_TYPE_P ('))))
	{
	  rtx loc[8];
	  int offset;
	  int bytesize;
	  int i;

	  offset = 0;
	  bytesize = int_size_in_bytes (valtype);
	  for (i = 0; offset < bytesize; i++)
	    {
	      loc[i] = gen_rtx_EXPR_LIST (VOIDmode,
					  gen_rtx_REG (DImode,
						       GR_RET_FIRST + i),
					  GEN_INT (offset));
	      offset += UNITS_PER_WORD;
	    }
	  return gen_rtx_PARALLEL (mode, gen_rtvec_v (i, loc));
	}
      else
	return gen_rtx_REG (mode, GR_RET_FIRST);
    }

Note that we already test the type 'valtype'.  Moreover, int_size_in_bytes is 
invoked unconditionally on 'valtype' and would segfault if it was 0, so 
valtype is set every time mode == BLKmode.  So I think having a non-BLKmode 
on records with a single integer field would not change anything as far as 
the return value is concerned.

What do you think?  Thanks in advance.

-- 
Eric Botcazou

Re: MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[James E Wilson]

Eric Botcazou wrote:
> The HP-UX port on the IA-64 architecture defines the MEMBER_TYPE_FORCES_BLK 
> macro with this comment:

Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented 
the ia64-hpux port.  At the time, I mentioned using PARALLELs was a 
better solution, but this was a simpler way for him to get the initial 
port working.  Since then, there have been a lot of bug fixes to the 
ia64-hpux support by various people: Steve, Zack, Joseph, etc.  Looking 
at the current code, it does appear that all cases are now handled by 
PARALLELs, and that the definition of MEMBER_TYPE_FORCES_BLK no longer 
appears to be necessary.

I don't have an ia64-hpux machine, so there is no easy way for me to 
test this change.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[Eric Botcazou]

> Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented
> the ia64-hpux port.  At the time, I mentioned using PARALLELs was a
> better solution, but this was a simpler way for him to get the initial
> port working.  Since then, there have been a lot of bug fixes to the
> ia64-hpux support by various people: Steve, Zack, Joseph, etc.  Looking
> at the current code, it does appear that all cases are now handled by
> PARALLELs, and that the definition of MEMBER_TYPE_FORCES_BLK no longer
> appears to be necessary.

Running the 2 GCC compatibility testsuites between the unpatched and the 
patched compiled indeed shows that this part of MEMBER_TYPE_FORCES_BLK is now 
useless for the purpose it was initially defined.  Moreover, removing it 
doesn't trigger any new failure in the testsuite except in one corner case (a 
GNU extension); but that can be easily patched in ia64_function_arg.

I plan on submitting a patch to Steve and you next week.

Thanks for your feedback.

-- 
Eric Botcazou

Re: MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[Steve Ellcey]

> Steve Ellcey defined MEMBER_TYPE_FORCES_BLK when he first implemented 
> the ia64-hpux port.  At the time, I mentioned using PARALLELs was a 
> better solution, but this was a simpler way for him to get the initial 
> port working.  Since then, there have been a lot of bug fixes to the 
> ia64-hpux support by various people: Steve, Zack, Joseph, etc.  Looking 
> at the current code, it does appear that all cases are now handled by 
> PARALLELs, and that the definition of MEMBER_TYPE_FORCES_BLK no longer 
> appears to be necessary.
> 
> I don't have an ia64-hpux machine, so there is no easy way for me to 
> test this change.
> -- 
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

I am concerned about the use of MEMBER_TYPE_FORCES_BLK in stor-layout.c.
I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
change the mode of a structure containing a single field from BLKmode
into the mode of the field.  I think this might mess up the parameter
passing of structures that contain a single field, particularly when
that field is smaller than 64 bits, like a single char, an int, or a
float.  I would definitely want to check the parameter passing of small
single field structures before removing MEMBER_TYPE_FORCES_BLK on
ia64-hpux.

Steve Ellcey
sje@cup.hp.com

Re: MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[Eric Botcazou]

> I am concerned about the use of MEMBER_TYPE_FORCES_BLK in stor-layout.c.
> I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
> change the mode of a structure containing a single field from BLKmode
> into the mode of the field.

Right, that's precisely what we would need for Ada.

> I think this might mess up the parameter passing of structures that contain
> a single field, particularly when that field is smaller than 64 bits, like a
> single char, an int, or a float.

Running the 2 compat testsuites shows that this actually doesn't happen.

-- 
Eric Botcazou

Re: MEMBER_TYPE_FORCES_BLK on IA-64/HP-UX

[James E Wilson]

On Sun, 2005-07-03 at 09:13, Steve Ellcey wrote:
> I believe that, if MEMBER_TYPE_FORCES_BLK is not defined, this code will
> change the mode of a structure containing a single field from BLKmode
> into the mode of the field.

This is why we should be checking types in ia64_function_arg instead of
modes.  The types are not affected by the mode changes that occur in
stor-layout.c.  It appears that we are doing this correctly already. 
Note the checks for AGGREGATE_TYPE_P.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com