[llvm] r225800 - [PowerPC] Add DWARF numbers for CA (XER), etc.

[David Blaikie]

On Tue, Jan 13, 2015 at 10:12 AM, Hal Finkel <hfinkel at anl.gov> wrote:

> ----- Original Message -----
> > From: "David Blaikie" <dblaikie at gmail.com>
> > To: "Hal Finkel" <hfinkel at anl.gov>
> > Cc: llvm-commits at cs.uiuc.edu
> > Sent: Tuesday, January 13, 2015 12:08:42 PM
> > Subject: Re: [llvm] r225800 - [PowerPC] Add DWARF numbers for CA (XER),
> etc.
> >
> >
> > On Tue, Jan 13, 2015 at 9:45 AM, Hal Finkel < hfinkel at anl.gov >
> > wrote:
> >
> >
> > Author: hfinkel
> > Date: Tue Jan 13 11:45:11 2015
> > New Revision: 225800
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=225800&view=rev
> > Log:
> > [PowerPC] Add DWARF numbers for CA (XER), etc.
> >
> >
> > Worth having some tests for this?
> >
> >
>
> Not sure how to test this directly.


Given that this adds DWARF numbers, I would've imagined a debug info test
ensuring that certain register references are correctly encoded (though
admittedly, such a test would probably be prone to the whims of the
register allocator - not sure if you could create a test case that
sufficiently constrained things so as to make that reliable).


> The stackmap/patchpoint tests, however, will assert without it.
>

Not sure what other people prefer, but usually if I find a test fails on a
particular architecture (especially other than the one I developed the test
on), I'll add a target-triple version of the test to demonstrate the
failure/fix in a portable way when I commit it - that way I can verify the
fix locally, etc.

Just some thoughts, nothing critical.

- David


>
>  -Hal
>
> >
> > For registers that have DWARF numbers (like CA, which is really part
> > of XER),
> > add them. Also, RM is not an SPR, and the declaration hack (where it
> > is
> > declared as an SPR with an arbitrary number) is not needed, so just
> > declare it
> > as a register.
> >
> > NFC; although CA's register number will be needed when
> > stackmap/patchpoint
> > support is added.
> >
> > Modified:
> > llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td
> >
> > Modified: llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td
> > URL:
> >
> http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td?rev=225800&r1=225799&r2=225800&view=diff
> >
> ==============================================================================
> > --- llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td (original)
> > +++ llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td Tue Jan 13
> > 11:45:11 2015
> > @@ -131,8 +131,8 @@ foreach Index = 0-31 in {
> > }
> >
> > // The reprsentation of r0 when treated as the constant 0.
> > -def ZERO : GPR<0, "0">;
> > -def ZERO8 : GP8<ZERO, "0">;
> > +def ZERO : GPR<0, "0">, DwarfRegAlias<R0>;
> > +def ZERO8 : GP8<ZERO, "0">, DwarfRegAlias<X0>;
> >
> > // Representations of the frame pointer used by ISD::FRAMEADDR.
> > def FP : GPR<0 /* arbitrary */, "**FRAME POINTER**">;
> > @@ -203,7 +203,7 @@ def VRSAVE: SPR<256, "vrsave">, DwarfReg
> > // Carry bit. In the architecture this is really bit 0 of the XER
> > register
> > // (which really is SPR register 1); this is the only bit interesting
> > to a
> > // compiler.
> > -def CARRY: SPR<1, "ca">;
> > +def CARRY: SPR<1, "ca">, DwarfRegNum<[76]>;
> >
> > // FP rounding mode: bits 30 and 31 of the FP status and control
> > register
> > // This is not allocated as a normal register; it appears only in
> > @@ -212,8 +212,7 @@ def CARRY: SPR<1, "ca">;
> > // most registers, it has to be done in code; to make this work all
> > the
> > // return and call instructions are described as Uses of RM, so
> > instructions
> > // that do nothing but change RM will not get deleted.
> > -// Also, in the architecture it is not really a SPR; 512 is
> > arbitrary.
> > -def RM: SPR<512, "**ROUNDING MODE**">;
> > +def RM: PPCReg<"**ROUNDING MODE**">;
> >
> > /// Register classes
> > // Allocate volatiles first
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >
> >
>
> --
> 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-commits/attachments/20150113/515a6edc/attachment.html>