[LLVMdev] Q about instruction pattern matching

Christopher Lamb christopher.lamb at gmail.com
Tue Oct 2 22:46:16 PDT 2007


On Oct 1, 2007, at 3:10 PM, Evan Cheng wrote:

>
> On Oct 1, 2007, at 12:09 AM, Andreas Fredriksson wrote:
>
>> On 10/1/07, Evan Cheng <evan.cheng at apple.com> wrote:
>>
>>>> If I lower the calling convention stuff manually rather than  
>>>> relying
>>>> on the generated CC analyzer, how do I determine that a formal
>>>> argument I'm about to receive or pack together is supposed to be
>>>> used
>>>> as a pointer so I can stick it in an address register?
>>>
>>> I'd suggest custom lowering for now. Again use data registers during
>>> lowering and fix them during the isel post pass if the parameters  
>>> are
>>> used as pointers. Do you think that would work?
>>
>> I guess in a regparm ABI like the one I'm targeting, LLVM will  
>> produce
>> "live ins" for the registers that are used in the ABI in the entry
>> basic block of all functions? I've seen "Live ins: D0" appear for an
>> int (int)-type signature, so that seems right.
>
> Right.
>
>> I'd like to arrange for e.g. a void foo(char*p) signature so see a
>> "live in A0", but can I custom lower to that immediately given that
>> I'm going to do a tapdance with the instruction selections later on?
>> If not, how do I distinguish these arguments from the data argument
>> later on?
>
> Hrm. I suspect you'll have to add parameter attribute (see
> ParameterAttributes.h) that indicates it's used as an address. In
> SelectionDAGIsel.cpp:TargetLowering::LowerAguments(), you have access
> to the function argument type. Anyone sees an alternative solution?

For the uses you can always emit D->A register copies before the  
uses, and then optimize this. However, I don't see any way around  
this for lowering arguments to a call.

--
Christopher Lamb



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071002/b04f9f84/attachment.html>


More information about the llvm-dev mailing list