<div dir="ltr"><div><div>I've managed to resolve this issue. It was related to how the live intervals were being updated during pre-RA scheduling. When an instruction is moved during pre-RA scheduling we need to call the function "<span style="font-family:monospace,monospace">LiveIntervals::handleMove</span>" to update the live intervals associated with that instruction. The trouble was that we were unable to do this for bundle header instructions. The reason for this is that there is an assertion in "<span style="font-family:monospace,monospace">handleMove</span>" that the instruction cannot be bundled. I believe that this assertion is invalid, and should instead be that the instruction cannot be <b>inside </b>a bundle. This means that the assertion still blocks attempted calls with instructions inside bundles, but doesn't prevent updating the bundle header. The live intervals for instructions inside the bundle should be updated at the same time as the bundle header. I've created a patch to this effect and have submitted it to llvm-commits for review.<br><br></div>Thanks,<br></div>Stephen<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 March 2016 at 13:24, Stephen Rogers <span dir="ltr"><<a href="mailto:stephen.rogers@movidius.com" target="_blank">stephen.rogers@movidius.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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><div class="h5"><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><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>
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><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><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><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><br>
mem:LD8[FixedStack64] VRF64_l:%vreg375<br></span>
6800B%vreg306<def,tied1> = foo %vreg306<tied0>, %vreg375, 14, pred:1,<span><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><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><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><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>
<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></div></div>
</blockquote></div><br></div>