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? 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"? 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080714/93c6b1f4/attachment.html>
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>
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>