On Feb 27, 2013, at 3:17 PM, Eric Christopher <[email protected]> wrote:

> 
> 
> 
> On Wed, Feb 27, 2013 at 11:49 AM, John McCall <[email protected]> wrote:
> On Feb 27, 2013, at 11:42 AM, Eric Christopher <[email protected]> wrote:
>> On Wed, Feb 27, 2013 at 11:39 AM, Adrian Prantl <[email protected]> wrote:
>> 
>> On Feb 27, 2013, at 11:31 AM, John McCall <[email protected]> wrote:
>> > Okay, you're saying that the value is actually no longer live at all at 
>> > this point in the function?  It seems reasonable to lose track of the 
>> > debug info then, although we should be leaving behind a marker in the 
>> > DWARF that says the value is unavailable.
>> >
>> > If we want to make stronger guarantees in -O0 for purposes of debugging — 
>> > and I think that's reasonable — then throwing the value in an alloca is 
>> > acceptable.
>> 
>> To clarify: Are you suggesting to only generate the alloca at -O0, or are 
>> you comfortable with it as it is?
>> 
>> If the value isn't live past that spot I'm more comfortable with dropping 
>> the debug info there rather than changing the generated code to keep the 
>> value live through the end of the function.
> 
> Purely out of attachment to the principle that debug info shouldn't change 
> the code?
> 
> 
> Pretty much.
>  
> Not losing information has intrinsic value in a debug build.  If we need to 
> emit slightly different code in order to force a value to stay live and thus 
> improve the debugging experience, then so be it.
> 
> 
> Agreed that making the experience better is desirable, but it can make 
> debugging a problem more difficult if the code changes when you turn on 
> debugging symbols.

I agree that turning on -g should not yield different code, but this is not 
what the patch does. Right now it changes code generation for all optimization 
levels. In the sake of efficiency we could emit the extra alloca at -O0 only. 
Would that work for you?

— adrian
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to