llvm dev - Jul 2016 - Preventing LLVM from optimizing out a variable

I have code along the lines of:

void foo(struct A *a) {
    struct B *b = a->m_B;
    /* do a whole bunch of things with b */
}

When LLVM generates code for this, it sees that after initializing b, a is
no longer used, so it is optimized out.

Unfortunately, for debug, I'd like the value for a to be kept around, if
only so that I can determine the value of b and go from there.  I don't
care if a is spilled to the stack and never referenced thereafter, as long
as it is available for debug.

Is there any way of marking a Value* as "precious", not to be
optimized out?

Simply storing a to a local variable (result of alloca in the first basic
block) and calling llvm.dbg.declare does not appear to be sufficient:

define void @foo(%A*) {
    %2 = alloca %A*
    store %0, %2
    call void @llvm.dbg.declare(metadata %A* %2, metadata !101, metadata
!100), !dbg ...

!100 = !DIExpression()
!101 = !DILocalVariable(...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160711/1e884d02/attachment.html>

On 11 July 2016 at 13:45, David Jones via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Is there any way of marking a Value* as "precious", not to be
optimized out?
I don't think there's any canonically supported way to do it.
> define void @foo(%A*) {
>     %2 = alloca %A*
>     store %0, %2
Perhaps mark this store as volatile? Untested, but worth a shot.

Tim.

If you mark that store as `volatile`, then LLVM should be unable to remove
it or the alloca (while still being free to do load-store forwarding, if it
deems that profitable), which should usually also keep the debug info
intact as a side-benefit.

On Mon, Jul 11, 2016 at 4:45 PM David Jones via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I have code along the lines of:
>
> void foo(struct A *a) {
>     struct B *b = a->m_B;
>     /* do a whole bunch of things with b */
> }
>
> When LLVM generates code for this, it sees that after initializing b, a is
> no longer used, so it is optimized out.
>
> Unfortunately, for debug, I'd like the value for a to be kept around,
if
> only so that I can determine the value of b and go from there.  I don't
> care if a is spilled to the stack and never referenced thereafter, as long
> as it is available for debug.
>
> Is there any way of marking a Value* as "precious", not to be
optimized
> out?
>
> Simply storing a to a local variable (result of alloca in the first basic
> block) and calling llvm.dbg.declare does not appear to be sufficient:
>
> define void @foo(%A*) {
>     %2 = alloca %A*
>     store %0, %2
>     call void @llvm.dbg.declare(metadata %A* %2, metadata !101, metadata
> !100), !dbg ...
>
> !100 = !DIExpression()
> !101 = !DILocalVariable(...)
>
>
> _______________________________________________
> 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/20160711/b0c9e312/attachment.html>

We've used this in the past:

#define KEEP_ALIVE(t) asm volatile("" : : "X"(t))

On Mon, Jul 11, 2016 at 1:45 PM, David Jones via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I have code along the lines of:
>
> void foo(struct A *a) {
>     struct B *b = a->m_B;
>     /* do a whole bunch of things with b */
> }
>
> When LLVM generates code for this, it sees that after initializing b, a is
> no longer used, so it is optimized out.
>
> Unfortunately, for debug, I'd like the value for a to be kept around,
if
> only so that I can determine the value of b and go from there.  I don't
> care if a is spilled to the stack and never referenced thereafter, as long
> as it is available for debug.
>
> Is there any way of marking a Value* as "precious", not to be
optimized
> out?
>
> Simply storing a to a local variable (result of alloca in the first basic
> block) and calling llvm.dbg.declare does not appear to be sufficient:
>
> define void @foo(%A*) {
>     %2 = alloca %A*
>     store %0, %2
>     call void @llvm.dbg.declare(metadata %A* %2, metadata !101, metadata
> !100), !dbg ...
>
> !100 = !DIExpression()
> !101 = !DILocalVariable(...)
>
>
>
> _______________________________________________
> 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/20160711/e92d1f14/attachment.html>

FyI, we (at Sony) have been experimenting with a way to keep local variables and
parameters alive past their point of last use by generating an artificial
(fake)use later in the instruction chain. Concretely, the idea is that the FE –
under control of a command line option – generates calls to a fake.use intrinsic
for all locals and parameters at or near the end of their respective lexical
scopes. LLVM turns the intrinsic calls eventually into FAKE_USE machine
instructions, which generate no code, but otherwise force the compiler to treat
their operands as if they were live, keeping them around in registers or
spilling them to the stack if necessary. Appropriate debug information is
generated automatically.

So far we found that this can definitely improve debugging in the situations you
describe at the expense of a slight performance penalty. We have floated this
idea  - restricted to the ‘this’ pointer - previously
(http://lists.llvm.org/pipermail/llvm-dev/2015-September/090663.html), but the
general community response was not favorable.

We still believe, however, that this feature could improve debugging of
optimized code, which is quite important to our user community (game
developers). We are currently in the process of gathering quantifiable data on
the impact on location information and performance.

-- Wolfgang

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David
Jones via llvm-dev
Sent: Monday, July 11, 2016 1:45 PM
To: llvm-dev
Subject: [llvm-dev] Preventing LLVM from optimizing out a variable

I have code along the lines of:
void foo(struct A *a) {
    struct B *b = a->m_B;
    /* do a whole bunch of things with b */
}
When LLVM generates code for this, it sees that after initializing b, a is no
longer used, so it is optimized out.
Unfortunately, for debug, I'd like the value for a to be kept around, if
only so that I can determine the value of b and go from there.  I don't care
if a is spilled to the stack and never referenced thereafter, as long as it is
available for debug.
Is there any way of marking a Value* as "precious", not to be
optimized out?
Simply storing a to a local variable (result of alloca in the first basic block)
and calling llvm.dbg.declare does not appear to be sufficient:
define void @foo(%A*) {
    %2 = alloca %A*
    store %0, %2
    call void @llvm.dbg.declare(metadata %A* %2, metadata !101, metadata !100),
!dbg ...
!100 = !DIExpression()
!101 = !DILocalVariable(...)

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

How about making your FAKE_USE instruction take a lot of arguments and
return the first one? Then you could have the return instruction depend on
it.

On Fri, Jul 15, 2016 at 10:28 AM, Pieb, Wolfgang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> FyI, we (at Sony) have been experimenting with a way to keep local
> variables and parameters alive past their point of last use by generating
> an artificial (fake)use later in the instruction chain. Concretely, the
> idea is that the FE – under control of a command line option – generates
> calls to a fake.use intrinsic for all locals and parameters at or near the
> end of their respective lexical scopes. LLVM turns the intrinsic calls
> eventually into FAKE_USE machine instructions, which generate no code, but
> otherwise force the compiler to treat their operands as if they were live,
> keeping them around in registers or spilling them to the stack if
> necessary. Appropriate debug information is generated automatically.
>
>
>
> So far we found that this can definitely improve debugging in the
> situations you describe at the expense of a slight performance penalty. We
> have floated this idea  - restricted to the ‘this’ pointer - previously (
> http://lists.llvm.org/pipermail/llvm-dev/2015-September/090663.html), but
> the general community response was not favorable.
>
>
>
> We still believe, however, that this feature could improve debugging of
> optimized code, which is quite important to our user community (game
> developers). We are currently in the process of gathering quantifiable data
> on the impact on location information and performance.
>
>
>
> -- Wolfgang
>
>
>
> *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of
*David
> Jones via llvm-dev
> *Sent:* Monday, July 11, 2016 1:45 PM
> *To:* llvm-dev
> *Subject:* [llvm-dev] Preventing LLVM from optimizing out a variable
>
>
>
> I have code along the lines of:
>
> void foo(struct A *a) {
>
>     struct B *b = a->m_B;
>
>     /* do a whole bunch of things with b */
> }
>
> When LLVM generates code for this, it sees that after initializing b, a is
> no longer used, so it is optimized out.
>
> Unfortunately, for debug, I'd like the value for a to be kept around,
if
> only so that I can determine the value of b and go from there.  I don't
> care if a is spilled to the stack and never referenced thereafter, as long
> as it is available for debug.
>
> Is there any way of marking a Value* as "precious", not to be
optimized
> out?
>
> Simply storing a to a local variable (result of alloca in the first basic
> block) and calling llvm.dbg.declare does not appear to be sufficient:
>
> define void @foo(%A*) {
>
>     %2 = alloca %A*
>
>     store %0, %2
>
>     call void @llvm.dbg.declare(metadata %A* %2, metadata !101, metadata
> !100), !dbg ...
>
> !100 = !DIExpression()
>
> !101 = !DILocalVariable(...)
>
>
>
> _______________________________________________
> 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/20160716/b38c0669/attachment.html>