[LLVMdev] Regarding ARM CodeGen

[Evan Cheng]

On Jul 14, 2008, at 5:10 PM, kapil anand wrote:

> Hi Evan,
>
> Thanks for the answers. I had few more queries though.
>
> 1. As far as I was able to understand the Codegen infrastructure,  
> ARMInstrInfo.td file has complete description of the instructions  
> which modify the status flags. For example, we have description for  
> both ADD and ADDS. But the problem is that in LLVM, we have a single  
> "ADD" Instruction. Thus when we do getDesc(add), we get the  
> descripiton corresponding to "ADD". When I was reading the code, I  
> got a feeling that if we are able to modify this selection of "ADD"  
> to "ADDS"( provided we somehow determine that we need ADDS here),  
> then everything else related to ARM instruction generation has been  
> handled in current infrastructure. Is this correct or do we need to  
> modify other things also?

The short answer is we'll need to modify other things. It's possible  
to custom lower setcc / select_cc, etc. to handle some the cases and  
enable selection of ADDS. But it won't be a very generic fix. The  
right fix is to add a pass to optimize away the cmp instruction by  
*folding* it in the preceding add when it's legal. Ideally this will  
be a target independent pass that x86 and other targets can take  
advantage of as well.

>
>
> 2. In file ARMISelLowering.cpp, inside function FPCCtoARMCC,  
> condition ISD::SETO generates ARMCC::VC ( Overflow clear) condition.  
> Thus, if we are able to appropriately generate ISD::SETO inside  
> SDNode for overflow clear and then map it to ARMCC::VC instruction  
> in IntCCtoARMCC, then will that be enough to generate the an  
> instruction like "addvc"?

addvc means "executing the add when overflow clear"? Then yes, that  
will happen as a result of if conversion if the incoming instruction  
selection input looks like that.

Evan

>
>
> Thanks
>
> Regards,
> Kapil Anand
>
> On Mon, Jul 14, 2008 at 6:10 PM, Evan Cheng <evan.cheng at apple.com>  
> wrote:
>
> On Jul 14, 2008, at 12:59 PM, kapil anand wrote:
>
>> Hi all,
>>
>> I am using LLVM compiler and CodeGen  for generating ARM binaries.
>>
>> I was going through the code for ARM backend. I noticed that the  
>> ARM Condition field( Bits 31-28) is generated by converting the  
>> conditions used in icmp and branch. For example, if I have  
>> following C Code
>>
>> int a,b,c,d;
>> c = a+b;
>>
>> if(c==0)
>>      d = a + 10;
>>
>>
>> Then I get ( Assembly Instructions with opcodes only)
>>
>> add
>> cmp
>> addeq
>>
>>
>> ( basically converting branch to the predicate condition field)
>>
>> I have a few questions regarding the above operation.
>> 1. If I use GCC on above code, then I get following .s output:
>>    adds
>>    addeq
>>
>> I don't  get the intermediate compare instruction, which I got when  
>> I used LLVM. So, does LLVM ARM Backend assume that only "cmp" and  
>> "test" instructions can set the Status flags and not the usual  
>> arithmetic instructions. Is there any way of specifying to Backend  
>> that add can also modify status flag through "s" bit.
>
> Right. X86 backend has the same issue. It's not taking advantage of  
> the fact that instructions can set the condition register bits. It's  
> a known codegen deficiency. On x86 it's generally not a *huge* issue  
> but I have no idea what its impact is on various ARM implementations.
>
>>
>>
>> 2. Also, when I looked at ISelLowering file, I noticed that  
>> conditions used in "icmp" instructions are converted to ARM  
>> Predicate Condition fields. Icmp has only "10" conditions, which  
>> map to corresponding "10" conditions in ARM Condition field but ARM  
>> can have fourteen conditions. If we consider the mapping shown in  
>> ISelLowering File, then following four conditions are left:
>> "VS": Overflow Set
>> "VC" : Overflow Clear
>> "MI" : Minus
>> "PL": Plus
>>
>> So, does this mean that it is not possible to obtain the above  
>> conditions are predicate if we use LLVM Compiler framework.
>
> It's not clear to me how those are modeled in the llvm level.
>
> Evan
>
>>
>>
>> Thanks
>>
>> Regards,
>> Kapil Anand
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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