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: ia64-hpux fix compat/struct-by-value-5


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.

If you do not use a parallel, then the compiler assumes that you want
right-alignment always.  See assign_parms.

The result is that you can get the two most common types of sub-word
alignment by carefully choosing whether you use a parallel or not.  This
is a bit of a hack, but it works for most targets.  assign_parms is old
code with the same behaviour going back to before 1990.  emit_group_load
is new code, with different behaviour, thus it can't break any old
targets that don't use it.

This evolved by accident.  I added emit_group_load to handle some
unusual calling conventions on Irix6, and then Richard Henderson
extended it to handle sparc64 which had similar problems, and in the
process Richard added the alignment hack because it was convenient way
to solve his problem.  Many ports have since been modified to take
advantage of this.  For instance, some very old very ugly hacks in the
mips port for argument alignment have been removed by simply using
parallels.

Ideally, there should be a way to tell the compiler what kind of
alignment you want for sub-word arguments and return values.  We could
extend the parallel scheme to include an alignment indicator, but then
we need to worry about backwards compatibility somehow.  I haven't
really given this much thought.

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.

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".
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com


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