<div dir="ltr">Hi Mikael,<div><br></div><div>I think you're right, the live range does seem to suggest that <font face="monospace, monospace">%vreg304</font> isn't live at <span style="font-size:12.8px">6796B. However from manual inspection of the code, I think that <font face="monospace, monospace">%vreg304</font> should be marked as live at that point.</span></div><div><br></div><div>There were several spills and reloads inserted before the allocation of <font face="monospace, monospace">%vreg375</font>. This made it very difficult to track what exactly was going on, so in the main while loop of "<font face="monospace, monospace">RegAllocBase::allocatePhysRegs</font>" I added a call to "<font face="monospace, monospace">LIS->dump()</font>" to print out the code for the whole function. I got the code I posted from the dump just before "<font face="monospace, monospace">RAGreedy::selectOrSplit</font>" was called for <font face="monospace, monospace">%vreg375</font>. I think this means the code I posted is correct at the time of allocation (unless some other changes are made to the code by "<font face="monospace, monospace">RAGreedy::selectOrSplit</font>" itself).</div><div><br></div><div>Thanks,</div><div>Stephen</div><div><br></div><div><br></div><div class="gmail_extra"><div class="gmail_quote">On 10 March 2016 at 13:07, Mikael Holmén <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<span class=""><br>
<br>
On 03/10/2016 12:34 PM, Stephen Rogers via llvm-dev wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
Hi all,<br>
<br>
I've come across a problem with register allocation which I have been<br>
unable to track down the root cause of.<br>
<br></span>
6728B%vreg304<def> = COPY %vreg278; VRF128:%vreg304,%vreg278<br>
6736B%vreg302<def> = COPY %vreg278; VRF128:%vreg302,%vreg278<br>
6752B%vreg278<def,tied1> = foo %vreg278<tied0>, %vreg277, 14, pred:1,<span class=""><br>
pred:%noreg, 5; VRF128:%vreg278 VRF64_l:%vreg277<br>
* bar 30, %vreg278; VRF128:%vreg278<br></span>
6760B%vreg302<def,tied1> = foo %vreg302<tied0>, %vreg270, 14, pred:1,<span class=""><br>
pred:%noreg, 5; VRF128:%vreg302 VRF64_l:%vreg270<br>
* bar 30, %vreg302; VRF128:%vreg302<br></span>
6768B%vreg304<def,tied1> = foo %vreg304<tied0>, %vreg263, 14, pred:1,<span class=""><br>
pred:%noreg, 5; VRF128:%vreg304 VRF64_l:%vreg263<br>
* bar 30, %vreg304; VRF128:%vreg304<br></span>
6776BSTORE128 %vreg302, <fi#32>, 0; mem:ST16[FixedStack32] VRF128:%vreg302<br>
6792B%vreg306<def> = COPY %vreg305; VRF128:%vreg306,%vreg305<br>
6796B%vreg375<def> = LOAD_v4i16 <fi#64>, 0, pred:1, pred:%noreg, 7;<span class=""><br>
mem:LD8[FixedStack64] VRF64_l:%vreg375<br></span>
6800B%vreg306<def,tied1> = foo %vreg306<tied0>, %vreg375, 14, pred:1,<span class=""><br>
pred:%noreg, 5; VRF128:%vreg306 VRF64_l:%vreg375<br>
* bar 30, %vreg306; VRF128:%vreg306<br></span>
6804BSTORE128 %vreg304, <fi#33>, 0; mem:ST16[FixedStack33] VRF128:%vreg304<span class=""><br>
<br>
For this sequence of instructions, when allocating a register for<br>
%vreg375 the greedy register allocator chooses V15_l. The problem here<br>
is that it had previously allocated V15 (V15_l is a sub-register of V15)<br>
to %vreg304. %vreg304 is defined at 6768B and finally used at 6804B so<br>
the instruction LOAD_v4i16 at 6796B ends up clobbering the value in<br></span>
V15before its last use. This is the output of the allocator itself:<span class=""><br>
<br>
selectOrSplit VRF64_l:%vreg375 [6796r,6800r:0) 0@6796r w=1.#INF00e+00<br>
assigning %vreg375 to %V15_l: V15_e0 [6796r,6800r:0) 0@6796r V15_e1<br>
[6796r,6800r:0) 0@6796r V15_e2 [6796r,6800r:0) 0@6796r V15_e3<br>
[6796r,6800r:0) 0@6796r<br>
<br>
And this is the live range of %vreg304 printed just before the<br>
allocation of %vreg375 started:<br>
<br>
</span></blockquote>
<br>
I've no idea what the problem is but this looks a little funny to me:<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
%vreg304 [6728r,6768r:0)[6800r,6804r:1) 0@6728r 1@6800r<br>
</blockquote>
<br></span>
According to this live range (if I can interpret the printouts...), %vreg304 is not live at e.g. 6796B, and thus I suppose V15 is free for %vreg375 at that point?<br>
<br>
Has %vreg304 been split/spilled before the allocation of %vreg375, so the code at that point is actually something different than all the instructions you posted above?<br>
<br>
Regards,<br>
Mikael<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<br>
Why is V15_l being allocated to %vreg375 when there is already a live<br>
value in V15? Am I missing some meta-data on either of the instructions<br>
foo or bar? The instruction bar doesn't clobber %vreg304.<br>
<br>
Thanks,<br>
Stephen<br>
<br>
<br></span>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div></div>