ia64-hpux fix compat/struct-by-value-5

[Zack Weinberg]

Jim Wilson <wilson@specifixinc.com> writes:

> On Tue, 2004-02-17 at 00:16, Zack Weinberg wrote:
>> This patch fixes the problem, but I do not understand why it works;
>> I discovered the idiom by staring at other parts of ia64_function_arg.
>
> If you use a parallel for an argument or return value, then the compiler
> assumes that you want left-alignment big-endian/right-alignment
> little-endian.  See the emit_group_{load,store} functions.  Actually,
> you have to look at gcc-3.3 or earlier, someone helpfully deleted the
> comment that documented this behaviour.
[...]

Thanks for the detailed explanation.

> Actually, I think we should rip out the entire argument passing
> interface, including the hundred or so macros that it uses, and replace
> it with one where we just pass the list of arguments to the backend, and
> the backend returns a structure saying where they all go.  But this is
> so much work that I will probably never try it.

I agree, this would be better.  It would also help with C++'s vtable
thunks, where what's really wanted is a way to talk about tweaking the
actual arguments at the tree level, but we don't have that so we get
per-backend goo instead.  Not that I have time to try to implement it,
either, but if you were interested in sketching out a design I could
probably lend a hand.


> FYI There is a known IA-64 ABI problem that we currently can't solve. 
> There is one case where IA-64 needs right-aligned
> big-endian/left-aligned little-endian, but there is no way to specify
> this.  This case occurs when you have an HFA argument consisting of all
> floats, there are more floats than there are float-regs left, there are
> int regs still available when the float-regs are full, and an odd number
> of floats were stored into FP regs.  In this case, we are supposed to
> put the next float arg in the int regs in the same place it would have
> been if the entire structure was put into int regs.  Since we have the
> second-half (least significant) part of a word, it needs to go
> right-aligned big-endian/left-aligned little-endian, and we are screwed,
> as there is currently no way to represent this.  This is documented in
> the ia64.c file, though perhaps not as clearly as it could be.  Search
> for "odd 4 byte hunk".

Yeah, I've seen this bit I thought this was dealt with by use of
SImode under certain conditions, instead of DImode, but maybe I was
wrong.

zw