On Mar 1, 2013, at 10:15 AM, Adrian Prantl <[email protected]> wrote:
> On Feb 28, 2013, at 11:20 AM, John McCall <[email protected]> wrote:
>> On Feb 28, 2013, at 11:12 AM, Eric Christopher <[email protected]> wrote:
>>> On Thu, Feb 28, 2013 at 11:06 AM, John McCall <[email protected]> wrote:
>>> 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.
>>> 
>>> Ah, I see your point;  not doing the alloca could slide stack frames around.
>>> 
>>> Alright, I agree with emitting it in all -O0 builds.
>>> 
>>> Thought if optimization should fix it then perhaps all builds? :)
>> 
>> I don't see any point in creating it just for mem2reg to trivially destroy. 
>> :)
>> 
>>> That said I'll remove the objection to the allocas. We'll need to fix the 
>>> alloca problem at some point, but making poor Adrian do it right now for 
>>> this bug when we've got other workarounds already in the source base seems 
>>> a bit mean.
>> 
>> Well, if the value really isn't live anymore, then I'm not sure what the 
>> supposed alloca problem is, other than needing to leave breadcrumbs to say 
>> that the value isn't available at this point in the function.  We definitely 
>> don't want regalloc to be keeping values live just for debug info!
> 
> FYI: this is what the patch looks like if output the alloca only at -O0.

+  if (CGM.getCodeGenOpts().OptimizationLevel == 0)
+    blockAddr = Builder.CreateLoad(blockAddr);

No.  The kind of value in LocalDeclMap should not vary according to
target optimization level.

What you should do is:
 - under -O0, always emit an alloca for the block context parameter and store
   the block context into it, and 
 - under -g, tie the debug info the block context parameter to the alloca, if it
   exists, and otherwise to the raw argument value.

+      if (CGM.getCodeGenOpts().OptimizationLevel == 0) {
+       llvm::Value *selfAddr =

Don't do this.  If you need to re-indent, re-indent.

+// RUN: %clang_cc1 %s -O0 -fblocks -triple x86_64-apple-darwin -emit-llvm -o - 
| FileCheck %s

I'm confused, because that's the default.

+// RUN: %clang -fblocks -S -g -fverbose-asm -triple x86_64-apple-darwin -o - 
%s | FileCheck %s

Like Eric mentioned, tests that need to check backend output shouldn't go
in the clang test suite.  Change the test to check IR output or move it to
LLVM.

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

Reply via email to