llvm dev - Sep 2015 - Fwd: extending liveness of 'this' pointer via FAKE_USE opcode

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)

>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150921/4843b441/attachment.html>

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Monday, September 21, 2015 11:23 AM
To: llvm-dev; Pieb, Wolfgang; Adrian Prantl; Frédéric Riss
Cc: Eric Christopher
Subject: Fwd: [llvm-dev] extending liveness of 'this' pointer via
FAKE_USE opcode

Oops, forgot to reply-all (& adding a few other people to the 'to'
line)
---------- Forwarded message ----------
From: David Blaikie <dblaikie at gmail.com<mailto: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<mailto: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<mailto: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)

With respect to the ‘this’ pointer, (or parameters in general) I have observed
register reuse after the last actual use of ‘this’. I haven’t seen any instance
of the register still holding the value while the debug info is not describing
it, but the sample of code I’ve looked at is not very large.

I’m still investigating locals in general.

 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?)

Preserving all variables is something we have done in a different compiler with
relatively minor performance degradation, and we would like to do this in LLVM
as well. The ‘this’ pointer and parameters in general are easier to implement
because their scope is easy to determine (and there’s been some definite
customer interest in the ‘this’ pointer).

 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)

In a different (proprietary) compiler we experimented with making all local
variables available throughout their respective lexical scope. The body of
evidence is not particularly large, but the performance degradation was in the
single digits. There is no data yet for LLVM/clang, but we are planning to
collect some.

 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?

Yes, we believe this would be a good idea.


Any comments or alternative ideas are appreciated.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150921/77106592/attachment.html>

> On Sep 21, 2015, at 1:41 PM, Pieb, Wolfgang <Wolfgang_Pieb at
playstation.sony.com> wrote:
> 
>  
>  
> From: David Blaikie [mailto:dblaikie at gmail.com <mailto:dblaikie at
gmail.com>]
> Sent: Monday, September 21, 2015 11:23 AM
> To: llvm-dev; Pieb, Wolfgang; Adrian Prantl; Frédéric Riss
> Cc: Eric Christopher
> Subject: Fwd: [llvm-dev] extending liveness of 'this' pointer via
FAKE_USE opcode
>  
> Oops, forgot to reply-all (& adding a few other people to the
'to' line)
> ---------- Forwarded message ----------
> From: David Blaikie <dblaikie at gmail.com <mailto: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
<mailto: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 <mailto: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)
>  
> With respect to the ‘this’ pointer, (or parameters in general) I have
observed register reuse after the last actual use of ‘this’. I haven’t seen any
instance of the register still holding the value while the debug info is not
describing it, but the sample of code I’ve looked at is not very large.
>  
> I’m still investigating locals in general.
Your experience does not sound very encouraging, but it would also be
interesting to monitor the impact of http://reviews.llvm.org/D11933
<http://reviews.llvm.org/D11933> regarding this problem.

— adrian
>  
>  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?)
>  
> Preserving all variables is something we have done in a different compiler
with relatively minor performance degradation, and we would like to do this in
LLVM as well. The ‘this’ pointer and parameters in general are easier to
implement because their scope is easy to determine (and there’s been some
definite customer interest in the ‘this’ pointer).
>  
>  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)
>  
> In a different (proprietary) compiler we experimented with making all local
variables available throughout their respective lexical scope. The body of
evidence is not particularly large, but the performance degradation was in the
single digits. There is no data yet for LLVM/clang, but we are planning to
collect some.
>  
>  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?
>  
> Yes, we believe this would be a good idea.
>  
>  
> Any comments or alternative ideas are appreciated.
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>  
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150921/50622fcc/attachment-0001.html>

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