[PATCH] D15614: TargetRegisterInfo: Add getRegAsmName()

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Sat Apr 9 13:54:09 PDT 2016


Sure.  I guess I was hoping for something else, but I don't have a strong
enough opinion when someone else really wants something

On Sat, Apr 9, 2016, 9:58 AM Hal Finkel <hfinkel at anl.gov> wrote:

> hfinkel added a subscriber: hfinkel.
> hfinkel accepted this revision.
> hfinkel added a reviewer: hfinkel.
> hfinkel added a comment.
> This revision is now accepted and ready to land.
>
> In http://reviews.llvm.org/D15614#338347, @tstellarAMD wrote:
>
> > In http://reviews.llvm.org/D15614#324163, @echristo wrote:
> >
> > > They did it via this:
> > >
> > >   class PPCReg<string n> : Register<n> {
> > >     let Namespace = "PPC";
> > >   }
> > >
> > >   // We identify all our registers with a 5-bit ID, for consistency's
> sake.
> > >
> > >   // GPR - One of the 32 32-bit general-purpose registers
> > >   class GPR<bits<5> num, string n> : PPCReg<n> {
> > >     let HWEncoding{4-0} = num;
> > >   }
> > >
> > >
> > > Where it just sets the register rather than using the default. Take a
> look at lib/Target/PPCRegisterInfo.td.
> >
> >
> > I'm not sure we are talking about this same thing, because this code
> appears to affect the encoding value and not the assembly string.
>
>
> That's right, this is a different issue. PPC does have a workaround for
> this:
>
>   // 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);
>
> and I'd like to get rid of this.
>
> This seems like a good first step; LGTM.
>
>
> http://reviews.llvm.org/D15614
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160409/c663c549/attachment.html>


More information about the llvm-commits mailing list