[LLVMdev] argument registers and -g

[Eric Christopher]

On Jul 10, 2012, at 8:56 PM, Peter Cooper <peter_cooper at apple.com> wrote:

> 
> On Jul 10, 2012, at 8:01 PM, Eric Christopher <echristo at apple.com> wrote:
> 
>> 
>> On Jul 10, 2012, at 7:57 PM, Peter Cooper <peter_cooper at apple.com> wrote:
>> 
>>> 
>>> On Jul 10, 2012, at 7:37 PM, Eric Christopher <echristo at apple.com> wrote:
>>> 
>>>> Hi Guys,
>>>> 
>>>> Pete's comment made Reed's question make sense to me :)
>>>> 
>>>> Pete is essentially correct, with some complications. You need to track the location of the arguments as they're going through code generation. Look at the llvm.dbg.value intrinsic as a guideline on how to track a variable through compilation and any saves should be marked.
>>>> 
>>>> We do support location lists in general (optimized code or code with many variables are impossible without it), but in the case you mention here:
>>>> 
>>>> void foo(int i) { // i is passed in a0 register
>>>> int j = i * 370;
>>>> // i is never used again
>>>> //// lots of deep expression code so that the a0 gets used again because it's a scratch register.
>>>> // this is okay, because we don't need it, but now in the debugger
>>>> // we can't display i because it has been clobbered.
>>>> 
>>>> you can treat it as "optimized" out. I can't think of a target that has this problem at the moment so you may need to look into what it would take to save the value out to the stack and then track it that way. I'm not a fan of that since that would mean that debug code gen is different from normal code gen. In general, this is a hard problem and there aren't any obvious solutions that I know about. One thing you'll want to make sure is that a variable has a proper address tag so that when it is clobbered you can express the lack of location to the user.
>>> Only thing i can think here is to always insert the saves from arguments into the stack then have an optimization to remove those saves if the values are unused (MachineDCE might already handle this?).  That optimization wouldn't run at O0 so you'd get the same behavior with and without -g, but at the expense of slightly worse code in non-debug -O0 builds.
>> 
>> Yeah, except having debug information avoid perturbing code gen is one of those "thou shalt avoid" commandments :)
> Ah, but thats why i suggested doing this entirely based on the optimization flag.  So always generate the stores to the stack (whether in debug mode or not), but only remove the stores if O1 or higher.

But it just seems... wrong to generate worse code at O0 on purpose :)

-eric