[llvm-commits] [llvm] r43988 - in /llvm/trunk: lib/Target/TargetCallingConv.td lib/Target/X86/X86CallingConv.td utils/TableGen/CallingConvEmitter.cpp

Dale Johannesen dalej at apple.com
Mon Nov 12 11:01:45 PST 2007


On Nov 12, 2007, at 10:48 AM, Duncan Sands wrote:

> Hi Dale,
>
>> I.e., I'm looking at it one level up, where you have
>>
>>   CCIfType<[f80], CCAssignToStackABISizeAlign<0>>
>>
>> So I like it this way (except for the annoying wart of the "ignored"
>> argument, maybe somebody knows a way around that?)
>
> supposing it is possible to get rid of the wart, how about the
> following: rename CCAssignToStack to CCAssignToStackSizeAlign,
> rename CCAssignToStackABISizeAlign to CCAssignToStack, go through
> all the uses of CCAssignToStackSizeAlign and if the size and
> alignment are just the ABI sizes and alignment (which presumably
> all of them are - this is almost the definition of the ABI size/
> alignment), drop the arguments and call CCAssignToStack instead.

I have no particular opinion on the renaming, except that  
interchanging the
names of two existing functions will create Confusion.  But yes,  
almost all
uses of CCAssignToStack could be replaced with the new 'function', and
IMO this would be a good idea.  I am not, however, planning to do it;
the danger of introducing a bug on some target I can't test outweighs
the benefits IMO.  I'd rather leave this to target maintainers.
(Also, there are a few exceptions, such as doubles on Sparc, which
are normally 8-byte aligned, but 4-byte aligned as arguments.  There
needs to be an override mechanism.)

> Why?  Because repeating the ABI size/alignment in all these CC
> calls is fragile and error prone (as proved by the long double
> trouble), so why do it?




More information about the llvm-commits mailing list