[llvm-dev] Fwd: extending liveness of 'this' pointer via FAKE_USE opcode

[Justin Bogner via llvm-dev]

David Blaikie via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Oops, forgot to reply-all (& adding a few other people to the 'to' line)
> ---------- Forwarded message ----------
> From: David Blaikie <dblaikie at gmail.com>
> Date: Mon, Sep 21, 2015 at 11:22 AM
> Subject: Re: [llvm-dev] extending liveness of 'this' pointer via FAKE_USE
> opcode
> To: "Pieb, Wolfgang" <Wolfgang_Pieb at playstation.sony.com>
>
>
>
>
> On Mon, Sep 21, 2015 at 11:16 AM, Pieb, Wolfgang via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hello!
>>
>>
>>
>> At Sony we've seen some serious customer interest in having the 'this'
>> pointer visible throughout an entire function during debugging. However,
>> optimizations may eliminate it after its last use, so we've been looking
>> for a way to artificially extend its liverange to the end of the function.
>>
>
> How much have you observed the actual (usually a register, yes?) register
> being reused, versus the debug info just not successfully describing its
> location? LLVM's optimized debug info still does a pretty bad job tracking
> optimized values (especially anything that gets promoted out of an alloca
> into a register)

In my experience, when the 'this' pointer is inaccessible when debugging
clang-generated code it's almost always the debug info failing to
describe the location. That is, I can very often find the correct value
by looking at the frame's registers.

I don't really see much value in trying to extend the live range until
after we've improved that situation, personally. Maybe you have a
different experience of how these issues come up than I do, though.

>
>>  So far, the most compelling way we can think of, and one we have used
>> successfully in the past in at least one other compiler,
>>
>> is to create a 'fake use' of the 'this' pointer at the end of the
>> function, compelling the rest of the compiler to not optimize it away.
>>
>
> Is there some more general heuristic we should consider rather than special
> casing the 'this' pointer? (something that might help other cases of
> parameters being optimized away entirely that would still be valuable to
> the user? Should we try to preserve all parameter values? All variables?)
>
>
>>  At the moment there doesn't seem to be a good way to create such a fake
>> use in LLVM (please enlighten us if you know of one), so we are
>>
>> proposing to introduce a new intrinsic (e.g. llvm.fake_use), which would
>> take a single value argument, representing a use of that value.
>>
>> The intrinsic would be lowered to a new invariant TargetOpcode (e.g.
>> FAKE_USE), which serves the same purpose at the MI level.
>>
>> Code emission would simply ignore the new opcode.
>>
>
>>
>> Frontends could use the intrinsic to extend liveranges of variables as
>> desired. As a first use case, clang would accept a new option
>>
>> (e.g. -fkeep-this-ptr) which would cause a fake use of 'this' to be
>> inserted at the end of a function, making it available for inspection
>>
>> throughout the entire function body.
>>
>
> Do you have much in the way of performance numbers to get a sense of the
> impact of this feature? (& possibly the impact with the sliding scale of
> "this pointer or all parameters or all variables" sort of thing)
>
>
>>  One important note is that since such an option would affect code
>> generation, it cannot be automatically enabled by -g. However, should there
>> be
>>
>> eventually support for a -Og mode (optimize for debugging), that mode
>> could enable it.
>>
>
> Is it worth considering adding -Og now/for this feature?
>
>
>>
>>
>> Any comments or alternative ideas are appreciated.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev