This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH 3.3 0203 i386/{i386.c,{i386elf,ptx4-i,sysv4}.h} for UnixWare build failure.


> Jan Hubicka <jh@suse.cz> writes:
> >
> > It is not clear to my why I am "moving to using
> > DEFAULT_PCC_STRUCT_RETURN over RETURN_IN_MEMORY".  I just have to
> > disable flag_pcc_struct_return for x86-64 that is enabled by default for
> > Linux. That was the only reason for that change.
> > I didn't intended to change anything else to be safe.
> >
> > Currently flag_pcc_struct_return controls the PS-ABI compiliant behaviour
> > where each structure is returned in memory (used by Linux for instance), 
> > and the "gcc" way of returning small structs in registers (used by BSD).
> >
> > I agree that it would be cleaner to have this decided in
> > x86_return_in_memory, but I wanted to first ensure whether you are
> > discussing some bug I introduced by the change, or future cleanup.
> 
> Okay, I see where the confusion is now.  I had three different things
> tangled up in my original post.
> 
> You did sort of introduce a bug, in that you induced new requirements
> on ix86 subtargets.  They now should not define RETURN_IN_MEMORY, and
> need to provide some definition of DEFAULT_PCC_STRUCT_RETURN, or
> i386.c will not compile.  Rodney's patch was addressing that problem.
> 
> Independent of that, I observe that the 32-bit case of ix86_return_in_memory
> reads
> 
>       if (TYPE_MODE (type) == BLKmode
> 	  || (VECTOR_MODE_P (TYPE_MODE (type))
> 	      && int_size_in_bytes (type) == 8)
> 	  || (int_size_in_bytes (type) > 12 && TYPE_MODE (type) != TImode
> 	      && TYPE_MODE (type) != TFmode
> 	      && !VECTOR_MODE_P (TYPE_MODE (type))))
> 	return 1;
>       return 0;
> 
> Now it is my understanding that "TYPE_MODE (type) == BLKmode" and
> "AGGREGATE_TYPE_P (type)" wind up being equivalent tests even though

I believe that small strucutures can have QI/HI/SI/DImodes, so this is
not equivalent and where the difference between
DEFAULT_PCC_STRUCT_RETURN beig 0/1 comes from.  Not dificult to fix.

Honza
> they base their test on different data.  I could be wrong about that.
> If I am correct, then the setting of DEFAULT_PCC_STRUCT_RETURN makes
> no difference on any 32-bit ix86 target, which means that we could
> make life easier for subtarget maintainers by putting an unconditional
> 
> #define DEFAULT_PCC_STRUCT_RETURN 0
> 
> in i386.h, removing all subtarget definitions of
> DEFAULT_PCC_STRUCT_RETURN and RETURN_IN_MEMORY, and removing the code
> in i386.c that diddles flag_pcc_struct_return.
> 
> Independent of *that*, I want to see -fpcc-struct-return go away and
> all targets use RETURN_IN_MEMORY exclusively to specify this part of
> their ABI.
> 
> zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]