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

Hal Finkel hfinkel at anl.gov
Tue Jan 13 10:23:06 PST 2015


----- 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:19:22 PM
> Subject: Re: [llvm] r225800 - [PowerPC] Add DWARF numbers for CA (XER), etc.
> 
> 
> 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).

Right, but this register is a control register. It is used for dependency tracking, but is never spilled, etc. and I don't think it ever appears in actual debug info. I added because I was working on stackmap support.

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

Agreed. This is not a target-dependent dependency, however (and the tests do have triples).

Thanks again,
Hal

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

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory



More information about the llvm-commits mailing list