[llvm-dev] Inline asm clobber registers name

[Hal Finkel via llvm-dev]

----- Original Message -----

> From: "Семен Колтон" <samkolton at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "via llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Friday, April 8, 2016 6:38:22 AM
> Subject: Re: [llvm-dev] Inline asm clobber registers name

> 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?
I think this sounds reasonable. I'll look at Tom's patch. 

-Hal 

> 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
> 

-- 

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/20160409/2ee77079/attachment-0001.html>