On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote:> It seems like d0 is always 14! > I check it with ARMGenAsmMatcher.inc it was the same! > How is it possible? because it should give the same register value that > matches the underlying platform not any autogenerated value!?The returned number is the register id as defined in <YourTarget>GenRegisterInfo.inc. These numbers don't have any meaning other than to represent a particular register. The 0x01 would be the encoding used in generating the binary. The D0 has id 14 on ARM because there are 13 other registers preceding it: namespace ARM { enum { NoRegister, APSR = 1, APSR_NZCV = 2, CPSR = 3, FPEXC = 4, FPINST = 5, FPSCR = 6, FPSCR_NZCV = 7, FPSID = 8, ITSTATE = 9, LR = 10, PC = 11, SP = 12, SPSR = 13, D0 = 14, ... -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
Hi Krzysztof,
Thanks for your reply. I wanted to assign the hardware encoding to the
Instruction bits like the link below:
https://groups.google.com/d/msg/llvm-dev/BfUmfIWYRM8/6JGXQf1gCQAJ
but, at the end, what is assigned to the Inst is, I suppose, the register
ID not the encoding!
to be more clear, I do the followings:
*def D0 : TestReg<0x01, "d0">, DwarfRegNum<[0]>;*
and then in InstInfo.td
*bits<6> Dr;let Inst{5-3} = Dr{2-0};*
assuming D0 is passed to $Dr, what I get in the encoding is 110, which I
think is the bit 0 to 2 of what is the returned value in the
TestGenAsmMatcher.inc.
I mean, at the end, Inst{5-3} is getting a value which is not 001.
What am I doing wrong?
On Thu, Sep 17, 2015 at 3:05 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 9/17/2015 7:04 AM, Sky Flyer via llvm-dev wrote:
>
>> It seems like d0 is always 14!
>> I check it with ARMGenAsmMatcher.inc it was the same!
>> How is it possible? because it should give the same register value that
>> matches the underlying platform not any autogenerated value!?
>>
>
> The returned number is the register id as defined in
> <YourTarget>GenRegisterInfo.inc. These numbers don't have any
meaning
> other than to represent a particular register. The 0x01 would be the
> encoding used in generating the binary.
>
> The D0 has id 14 on ARM because there are 13 other registers preceding it:
> namespace ARM {
> enum {
> NoRegister,
> APSR = 1,
> APSR_NZCV = 2,
> CPSR = 3,
> FPEXC = 4,
> FPINST = 5,
> FPSCR = 6,
> FPSCR_NZCV = 7,
> FPSID = 8,
> ITSTATE = 9,
> LR = 10,
> PC = 11,
> SP = 12,
> SPSR = 13,
> D0 = 14,
> ...
>
> -Krzysztof
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by The Linux Foundation
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150917/84c9da41/attachment.html>
On 9/17/2015 8:30 AM, Sky Flyer wrote:> Hi Krzysztof, > > Thanks for your reply. I wanted to assign the hardware encoding to the > Instruction bits like the link below: > > https://groups.google.com/d/msg/llvm-dev/BfUmfIWYRM8/6JGXQf1gCQAJ > > but, at the end, what is assigned to the Inst is, I suppose, the > register ID not the encoding! > > to be more clear, I do the followings: > *def D0 : TestReg<0x01, "d0">, DwarfRegNum<[0]>;* > > and then in InstInfo.td > *bits<6> Dr; > let Inst{5-3} = Dr{2-0};* > > assuming D0 is passed to $Dr, what I get in the encoding is 110, which I > think is the bit 0 to 2 of what is the returned value in the > TestGenAsmMatcher.inc. > I mean, at the end, Inst{5-3} is getting a value which is not 001. > What am I doing wrong? >I'm assuming that your TestReg definition assigns the 0x01 to the HWEncoding field. In an instruction definition, the way that tablegen assigns values from the parameters is that it goes over all undefined fields in the instruction class and assigns the values of the first argument to the first undefined field, the value of the second argument to the second undefined field, etc. What may be happening is that the D0 that you pass to the pattern is assigned to a different field that you expect. You can get all the expanded records from tablegen: llvm-tblgen -print-records -I [llvm source]/lib/Target/[your target] -I [llvm source]/lib/Target -I [llvm source]/include [llvm source]/lib/Target/Hexagon/[your target].td You should see the full class corresponding to the instruction definition, and see what fields in it are undefined. One thing that I'm not sure about is how table-gen handles types, for example, what it does if the argument is bits<5>, but there is an undefined field of type bits<1>. I don't know if it will skip it or truncate it to 1 bit. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation