[PATCH] Generate better location ranges for some register-described variables.

[Alexey Samsonov]

On Thu, Jun 5, 2014 at 5:55 PM, Alexey Samsonov <vonosmas at gmail.com> wrote:

>
> On Wed, Jun 4, 2014 at 5:18 PM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> I do rather feel this perhaps rises beyond my idea comfort level for
>> "work around" to "we should probably fix this the right way", but I realize
>> I'll probably be argued down on this.
>>
>> Out of curiosity, does anyone happen to be able to explain
>> LiveDebugVariables.cpp:956-966. It /looks/ like this code, based on the
>> comment, is trying to do what we want: add dbg.value intrinsics to every
>> basic block for which the variable is live. Any idea if this works? Why it
>> doesn't? etc...
>>
>
> This code doesn't work because the whole LiveDebugVariables pass is run
> only in greedy register allocator, while we use a fast register allocator
> in -O0 mode. From a brief examination, it seems
> that -livedebug pass is somewhat tied to greedy regalloc implementation,
> and we can't simply flip the flag and "enable" it unconditionally. However,
> we should go along this path:
> apparently we need this kind of analysis on all opt levels.
>
> I'd feel more comfortable to work on these passes, having suggested
> workaround applied, though.
>

In fact, I'm now going to apply this patch that would hopefully put us in
less fire-fighting position.
I've considered an alternative of whitelisting the set of registers which
are believed not to change in the function in the real-world, but we at
least need
both frame register and stack register in this set, while generic
TargetRegisterInfo gives us only the former. Extending this interface and
modifying a number
of backends is a more intrusive change.


>
>
>>
>> http://reviews.llvm.org/D3933
>>
>>
>>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>



-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140609/f10209b9/attachment.html>