[LLVMdev] Regarding ARM CodeGen

Tue Jul 15 08:35:58 PDT 2008

Hi,

I have one more query regarding the LLVM representations. In LLVM
Infrastructure, "label" is defined as Primitive type. So, is there any way
of using a variable of Type Label in some arithmetic operation or in
"bitcast" instruction.

I tried the following code:

*label %X1:
X1:
   %y = bitcast label %X1 to i32
    %tmp1 = add i32 %y,2*

llvm-as gave me an error that: "Basic block can't be used in line 3"
(Bitcast)

Is there any other way to use label in arithmetic operations. I am trying
this to represent Program counter in LLVM, since in ARM, we can have various
instructions which operate on PC , eg.

R2 = ADD PC,10

Thanks

Regards,
Kapil

On Mon, Jul 14, 2008 at 8:52 PM, Evan Cheng <evan.cheng at apple.com> wrote:

>
> 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
>
>
>
> _______________________________________________
> 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/20080715/8d16eacb/attachment.html>