This is the mail archive of the 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: function parms in regs, patch 3 of 3

This is the patch I really wanted to comment on, which is why I am willing to review this set of patches.

I believe that we already have so many macros that interact in confusing ways that we should avoid adding new ones. I think a better approach is to return more info from FUNCTION_ARG, in a more structured form, so that we can get away from the ever expanding set of macros that we have.
The PARALLEL stuff is a step in this direction. The structure of the info is ugly, but that can always be improved. I'd like to see the entire interface rewritten, but it isn't clear if anyone will ever have the time for it, and we could only do this in a .0 release.

Your revised patch which only defines BLOCK_REG_PADDING for rs6000 is a major improvement. I think there is too much risk in trying to define a default for all targets.

There is a known IA-64 ABI problem that your patch doesn't help with. The IA-64 ABI treats homogeneous floating-point aggregates (HFAs) specially. A structure all of whose fields are the same FP type is an HFA for instance. An HFA is passed in FP regs, one field per FP reg, until the FP regs are full, and then we pass the rest in integer regs.
The part passed in integer regs is placed in the same place it would have gone if the entire structure was passed in integer regs. Suppose we have a structure of 5 floats, and there are 3 FP registers left. The first 3 fields are passed in FP registers. The fourth one is passed left-justified (little-endian) in the second integer register, because it is the second half of the second word. The fifth one is passed right-justified (little-endian) in the third integer register, because it is the first half of the third word. Now the problem here is that a float field in an integer register can require either left or right justification depending on the context. I don't think your BLOCK_REG_PADDING macro can handle this. It doesn't have enough info. FUNCTION_ARG does have enough info. If the PARALLEL stuff had 3 items location/size/alignment instead of the current 2 location/size, then I believe we could fix this problem, your powerpc problem, and probably also some ABI problems in other ports that we may or may not know about.

Having said that, I really should take a closer look at the patch to see what it actually does. And I need to look at the second patch of the set.


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