<div dir="ltr">Hi Jon,<div><br></div><div>Sorry for being a bit unclear in what I wrote before:</div><div>By "undecidable", I meant that if the `computeRegisterLiveness` function can't determine CPSR liveness in the n-instruction window, it returns "Unknown", which I treat as if the CPSR was live. Increasing the window size allows us to get a conclusive result about CPSR liveness more often, thus allowing the optimization to happen (if CPSR is dead).</div><div><br></div><div>Cheers</div><div>Moritz</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 September 2014 14:37, Jonathan Roelofs <span dir="ltr"><<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 9/16/14 4:29 AM, Moritz Roth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Renato,<br>
<br>
unfortunately there is only ADDS (immediate) in Thumb1, so we have no choice :(<br>
<br>
I realised this morning that for this to work properly, the ADDS inserted to<br>
materialize the new base needs a <def,dead> of the CPSR (instead of just a def),<br>
so I added that to the patch. I also increased the neighbourhood size for<br>
computeRegisterLiveness slightly (10->15), as it turned out that quite often,<br>
CPSR liveness was undecidable in the default neighbourhood.<br>
</blockquote></span>
This doesn't sound correct to me. I think you need to calculate CPSR's liveness by looking at the whole basic block, not just a 15-instruction window.<br>
<br>
<br>
Jon<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And of course good point about the redundant comparison, I've removed that.<br>
<br>
Regarding the tests, you're right - I found this while working on making the<br>
load/store merging more aggressive (currently, we only do it if it's obviously<br>
safe) - the register allocator inserted some spills between a CMP and Bcc which<br>
could be merged, but it isn't possible to safely materialize the base+offset<br>
there. Unfortunately, with the algorithm that's currently checked in, the STRs<br>
in that case aren't merged at all, and it's somewhat dependent on register<br>
allocation...<br>
<br>
Cheers<br>
Moritz<br>
<br>
</blockquote>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded<br>
</font></span></blockquote></div><br></div>