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(…)

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.

We’ve used this in the past:

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

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

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.

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.

That would work for function level locals and parameters, but if you include nested locals it would extend their lifetime all the way to the end of the function. I’d be hesitant to do that because of performance/excessive spills etc.