[llvm-commits] [llvm] r46764 - in /llvm/trunk: include/llvm/CallingConv.h lib/Target/X86/X86CallingConv.td lib/Target/X86/X86ISelLowering.cpp

[Dale Johannesen]

On Feb 5, 2008, at 2:36 PM, Dale Johannesen wrote:
> On Feb 5, 2008, at 2:34 PM, Chris Lattner wrote:
>> On Feb 5, 2008, at 2:31 PM, Dale Johannesen wrote:
>>>> I think the calling convention stuff that Evan has been working  
>>>> on is
>>>> powerful enough to model though sort of stuff, but might need minor
>>>> extensions.  Do you think it would be reasonable do use this
>>>> approach?  Doing so would eliminate a "magic" calling convention,
>>>> which would be nice :)
>>>
>>> It would, but coercing standard types to a different type strikes me
>>> as worse.
>>> The IR really ought to be able to handle standard types without
>>> obfuscation.
>>
>> I don't think it would be a problem in this specific case, but I
>> understand what you mean.
>>
>>> What I really wanted was to put InReg on the return value.
>>
>> Ah, that's a good idea.  Why not do that? :)  Generally, putting the
>> attribute on argument "#0" means that the attribute applies to the
>> function or the return value.  Given that 'inreg' doesn't make any
>> sense for a function, it would be fine to overload it for this, what
>> do you think?
>
> Sound good if it's that simple.  It looked more complicated, but I
> was probably missing something.  I'll look again.

Attaching this to the Function node went smoothly enough, but I  
actually need it on the Return node, which it appears isn't supported  
in the current IR, but is in the the machine-level RET node.  I could  
transfer the info from the Function node to the RET node at some  
point, or even reference the Function node from the code that handles  
RET I suppose, but it seems cleaner to change the IR; which would  
break binary compatibility.   Considering that this works as is and is  
not all that important to begin with, I'm thinking it's best to wait  
until we can change the IR and do it right.  Thoughts?