[llvm-dev] Inline asm clobber registers name

[Семен Колтон via llvm-dev]

Hi Hal,


In that case I will start implementing it in core LLVM. What I want to do
is add table with AsmNames to TargetGenRegisterInfo.inc similar to
RegStrings table. This table could be used by getRegForInlineAsmConstraint.

I don’t want to force all back-ends to use AsmNames instead of def-names.
There is useful review for this created by Tom Stellard:
http://reviews.llvm.org/D15614.

What do you think about all this?


Thanks,

Sam

2016-04-07 18:46 GMT+03:00 Hal Finkel <hfinkel at anl.gov>:

>
>
> ------------------------------
>
> *From: *"Семен Колтон via llvm-dev" <llvm-dev at lists.llvm.org>
> *To: *"via llvm-dev" <llvm-dev at lists.llvm.org>
> *Sent: *Thursday, April 7, 2016 10:06:21 AM
> *Subject: *[llvm-dev] Inline asm clobber registers name
>
> Hi all,
>
>
> I am currently working on AMDGPU inline assembly and encountered problem
> with naming clobber registers in asm constraints. It looks like by default
> LLVM tries to match register specified in constraint to register name of
> register definition in .td file but not to the AsmName for this register.
>
>
> For example if we have register definition:
>
> def MYReg0 : Register<"r0", 0>;
>
> We want to create inline assembly and add this register to clobbers list.
> Inline assembly should look something like this:
>
>                 i32 asm "nop", "~{r0}" ()
>
>
> We used AsmName for register MYReg0 inside clobbers list. But this
> constraint fails to work because
> TargetLowering::getRegForInlineAsmConstraint() tries to match register
> definition name (“MYReg0”) not its AsmName (“r0”). So to make this work we
> should write this assembly:
>
>                 i32 asm "nop", "~{MYReg0}" ()
>
>
> I believe that this behavior is not correct. It works because in most
> back-ends register definition names and AsmNames are equal (e.g. def EAX
> : X86Reg<"eax", ...>) but in AMDGPU we want to have different def-names
> and AsmNames.
>
>
> This might be done by changing core LLVM code or in target-specific getRegForInlineAsmConstraint()
> method. What do you suppose to be better solution?
>
> I agree. I have the following FIXME in PPCISelLowering:
>
>   // r[0-9]+ are used, on PPC64, to refer to the corresponding 64-bit
> registers
>   // (which we call X[0-9]+). If a 64-bit value has been requested, and a
>   // 32-bit GPR has been selected, then 'upgrade' it to the 64-bit parent
>   // register.
>   // FIXME: If TargetLowering::getRegForInlineAsmConstraint could somehow
> use
>   // the AsmName field from *RegisterInfo.td, then this would not be
> necessary.
>   if (R.first && VT == MVT::i64 && Subtarget.isPPC64() &&
>       PPC::GPRCRegClass.contains(R.first))
>     return std::make_pair(TRI->getMatchingSuperReg(R.first,
>                             PPC::sub_32, &PPC::G8RCRegClass),
>                           &PPC::G8RCRegClass);
>
>  -Hal
>
>
> Thanks,
>
> Sam
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160408/5839a6bd/attachment-0001.html>