[LLVMdev] Purpose of MSP430Wrapper

Paul Shortis pauls at dataworx.com.au
Wed Jul 25 04:14:37 PDT 2012


On 25/07/12 18:21, Richard Osborne wrote:
> On 25 Jul 2012, at 04:49, Paul Shortis wrote:
>
>    
>> Hello,
>>
>> I'm considering creating an LLVM backend for a 16 bit processor and
>> modelling it around the (experimental) MSP430 back end.
>>
>> When reviewing MSP430InstrInfo.td I see
>>
>> def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>;
>>
>> and can see in MSP430ISelLowering.cpp that
>>
>> ISD::GlobalAddress:
>> ISD::BlockAddress:
>> ISD::ExternalSymbol
>>
>> all get lowered to MSP430ISD::Wrapper(address space) plus the wrapped
>> address node.
>>
>> What has me mystified is that in some of the patterns in
>> MSP430InstrInfo.td take the form
>>
>> def : Pat<(i16 (MSP430Wrapper tglobaladdr:$dst)), (MOV16ri
>> tglobaladdr:$dst)>;
>>
>> and others ...
>>
>> def : Pat<(MSP430call (i16 tglobaladdr:$dst)), (CALLi tglobaladdr:$dst)>;
>>
>> In other words, some patterns rely on MSP430Wrapper being part of the
>> pattern then extract the wrapped info anyway, and some others just
>> directly match tglobaladdr and friends.
>>
>> I have noticed that many other backends use the same idiom but so far I
>> can't see what it offers to the matching process.
>>
>> Can someone please explain what I'm not seeing ?
>>
>> Thanks, Paul.
>>      
> I'm not sure about the MSP430 backend but I can talk about the XCore backend which uses a similar idiom. The XCore has 3 ways of accessing a global: using PC relative addressing, via an immediate offset from the thread's DP (data pointer) register or via an immediate offset from the thread's CP (constant pool) register. When lowering a global address to a target global address XCoreISelLowering wraps the tglobaladdress node with one of three wrappers (PCRelativeWrapper, DPRelativeWrapper, CPRelativeWrapper) based on properties of the global (is it a function, is it constant, etc) .
>
> The wrapper is used in patterns in XCoreInstrInfo.td to ensure the right instruction is selected to access the global (for example to get the address of the global into a register the backend uses the LDAP instruction if the PCRelativeWrapper is present, LDAWCP if the CPRelativeWrapper is present and LDAWDP if the DPRelativeWrapper is present).
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>    
Thanks Richard,

You're correct, they are similar. In the XCoreInstrInfo.td patterns what 
I'm struggling with is why this ....

def BL_lu10 : _FLU10<
                   (outs),
                   (ins calltarget:$target, variable_ops),
                   "bl $target",
                   [(XCoreBranchLink immU20:$target)]>;

def : Pat<(XCoreBranchLink tglobaladdr:$addr), (BL_lu10 tglobaladdr:$addr)>;
def : Pat<(XCoreBranchLink texternalsym:$addr), (BL_lu10 
texternalsym:$addr)>;

is necessary. Are the Pat<> s just 'casting' tglobaladdr:$addr and 
texternalsym:$addr to an immU20 to force a match ?

I'm guessing similar Pat<> 's aren't required for the BL_u10/immU10 
cases because they match without any assistance ?

Is the XCoreBranchLink enough of a match hint that an address wrapper 
isn't required to clarify the pattern match for these call instructions ?

Cheers, Paul





More information about the llvm-dev mailing list