[Thumb] Don't materialize a new base register when CPSR is live

[Moritz Roth]

Hi Jon,

Sorry for being a bit unclear in what I wrote before:
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).

Cheers
Moritz



On 16 September 2014 14:37, Jonathan Roelofs <jonathan at codesourcery.com>
wrote:

>
>
> On 9/16/14 4:29 AM, Moritz Roth wrote:
>
>> Hi Renato,
>>
>> unfortunately there is only ADDS (immediate) in Thumb1, so we have no
>> choice :(
>>
>> I realised this morning that for this to work properly, the ADDS inserted
>> to
>> materialize the new base needs a <def,dead> of the CPSR (instead of just
>> a def),
>> so I added that to the patch. I also increased the neighbourhood size for
>> computeRegisterLiveness slightly (10->15), as it turned out that quite
>> often,
>> CPSR liveness was undecidable in the default neighbourhood.
>>
> 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.
>
>
> Jon
>
>
>> And of course good point about the redundant comparison, I've removed
>> that.
>>
>> Regarding the tests, you're right - I found this while working on making
>> the
>> load/store merging more aggressive (currently, we only do it if it's
>> obviously
>> safe) - the register allocator inserted some spills between a CMP and Bcc
>> which
>> could be merged, but it isn't possible to safely materialize the
>> base+offset
>> there. Unfortunately, with the algorithm that's currently checked in, the
>> STRs
>> in that case aren't merged at all, and it's somewhat dependent on register
>> allocation...
>>
>> Cheers
>> Moritz
>>
>>
> --
> Jon Roelofs
> jonathan at codesourcery.com
> CodeSourcery / Mentor Embedded
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140916/7ccdaeaa/attachment.html>