<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 13, 2015 at 10:12 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "David Blaikie" <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>><br>
> To: "Hal Finkel" <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>><br>
> Cc: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> Sent: Tuesday, January 13, 2015 12:08:42 PM<br>
> Subject: Re: [llvm] r225800 - [PowerPC] Add DWARF numbers for CA (XER), etc.<br>
><br>
><br>
> On Tue, Jan 13, 2015 at 9:45 AM, Hal Finkel < <a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a> ><br>
> wrote:<br>
><br>
><br>
> Author: hfinkel<br>
> Date: Tue Jan 13 11:45:11 2015<br>
> New Revision: 225800<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=225800&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=225800&view=rev</a><br>
> Log:<br>
> [PowerPC] Add DWARF numbers for CA (XER), etc.<br>
><br>
><br>
> Worth having some tests for this?<br>
><br>
><br>
<br>
</span>Not sure how to test this directly.</blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The stackmap/patchpoint tests, however, will assert without it.<br></blockquote><div><br>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.<br><br>Just some thoughts, nothing critical.<br><br>- David<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 -Hal<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> For registers that have DWARF numbers (like CA, which is really part<br>
> of XER),<br>
> add them. Also, RM is not an SPR, and the declaration hack (where it<br>
> is<br>
> declared as an SPR with an arbitrary number) is not needed, so just<br>
> declare it<br>
> as a register.<br>
><br>
> NFC; although CA's register number will be needed when<br>
> stackmap/patchpoint<br>
> support is added.<br>
><br>
> Modified:<br>
> llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td<br>
><br>
> Modified: llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td<br>
> URL:<br>
> <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td?rev=225800&r1=225799&r2=225800&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td?rev=225800&r1=225799&r2=225800&view=diff</a><br>
> ==============================================================================<br>
> --- llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td (original)<br>
> +++ llvm/trunk/lib/Target/PowerPC/PPCRegisterInfo.td Tue Jan 13<br>
> 11:45:11 2015<br>
> @@ -131,8 +131,8 @@ foreach Index = 0-31 in {<br>
> }<br>
><br>
> // The reprsentation of r0 when treated as the constant 0.<br>
> -def ZERO : GPR<0, "0">;<br>
> -def ZERO8 : GP8<ZERO, "0">;<br>
> +def ZERO : GPR<0, "0">, DwarfRegAlias<R0>;<br>
> +def ZERO8 : GP8<ZERO, "0">, DwarfRegAlias<X0>;<br>
><br>
> // Representations of the frame pointer used by ISD::FRAMEADDR.<br>
> def FP : GPR<0 /* arbitrary */, "**FRAME POINTER**">;<br>
> @@ -203,7 +203,7 @@ def VRSAVE: SPR<256, "vrsave">, DwarfReg<br>
> // Carry bit. In the architecture this is really bit 0 of the XER<br>
> register<br>
> // (which really is SPR register 1); this is the only bit interesting<br>
> to a<br>
> // compiler.<br>
> -def CARRY: SPR<1, "ca">;<br>
> +def CARRY: SPR<1, "ca">, DwarfRegNum<[76]>;<br>
><br>
> // FP rounding mode: bits 30 and 31 of the FP status and control<br>
> register<br>
> // This is not allocated as a normal register; it appears only in<br>
> @@ -212,8 +212,7 @@ def CARRY: SPR<1, "ca">;<br>
> // most registers, it has to be done in code; to make this work all<br>
> the<br>
> // return and call instructions are described as Uses of RM, so<br>
> instructions<br>
> // that do nothing but change RM will not get deleted.<br>
> -// Also, in the architecture it is not really a SPR; 512 is<br>
> arbitrary.<br>
> -def RM: SPR<512, "**ROUNDING MODE**">;<br>
> +def RM: PPCReg<"**ROUNDING MODE**">;<br>
><br>
> /// Register classes<br>
> // Allocate volatiles first<br>
><br>
><br>
> _______________________________________________<br>
> llvm-commits mailing list<br>
> <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
><br>
><br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span></blockquote></div><br></div></div>