This is an archive of the discontinued LLVM Phabricator instance.

PR32382: Adapt to LLVM changes in DIExpression.
AbandonedPublic

Authored by aprantl on Mar 28 2017, 2:09 PM.

Details

Summary

LLVM has changes the semantics of dbg.declare for describing function arguments. After this patch a dbg.declare always takes the *address* of a variable as the first argument, even if the argument is not an alloca.

https://bugs.llvm.org/show_bug.cgi?id=32382
rdar://problem/31205000

Diff Detail

Event Timeline

dblaikie edited edge metadata.Mar 29 2017, 10:50 AM

I'm a bit confused - the alloca was only emitted at -O0, by the looks of it. Presumably it's pessimizing in some way at higher optimization levels? Or is that not the case?

Also, it looks like this change lost the "if > gmlt" test, so might cause variable declarations (& thus types) to leak into GMLT, which is undesirable.

I'm a bit confused - the alloca was only emitted at -O0, by the looks of it. Presumably it's pessimizing in some way at higher optimization levels? Or is that not the case?

I think it is really working around the odd behavior of LLVM here. What gives it away is the we key the addition of the extra DW_OP_deref on whether it is an alloca or not. But note that this is not how dbg.declare works: dbg.declare(%alloca, !DIExpression()) is (kind of) equivalent to dbg.value(%alloca, !DIExpression(DW_OP_deref)). So we are using the presence of the alloca as a proxy for how the backend happens to compile the DwarfExpression here and work around its idiosyncrasy by emitting an extra DW_OP_deref.

Also, it looks like this change lost the "if > gmlt" test, so might cause variable declarations (& thus types) to leak into GMLT, which is undesirable.

Oh.. that was unintentional collateral damage. Thanks for noticing!

aprantl updated this revision to Diff 93897.Apr 3 2017, 11:29 AM

Add accidentally removed check for the debug info level back in.

aprantl updated this revision to Diff 93900.Apr 3 2017, 11:37 AM

I'm a bit confused - the alloca was only emitted at -O0, by the looks of it. Presumably it's pessimizing in some way at higher optimization levels? Or is that not the case?

I think it is really working around the odd behavior of LLVM here. What gives it away is the we key the addition of the extra DW_OP_deref on whether it is an alloca or not. But note that this is not how dbg.declare works: dbg.declare(%alloca, !DIExpression()) is (kind of) equivalent to dbg.value(%alloca, !DIExpression(DW_OP_deref)). So we are using the presence of the alloca as a proxy for how the backend happens to compile the DwarfExpression here and work around its idiosyncrasy by emitting an extra DW_OP_deref.

I'm still not really following, sorry - perhaps it'd help me if you could describe the state of things in ToT currently, the state this change attempts to create, and the state (if distinct from the previous) that might be ideal. (it's not clear to me if there's still a "workaround" after your change - sounds like there should be/is, if previously there was no alloca above O0 but after this change there will be... )

Also, it looks like this change lost the "if > gmlt" test, so might cause variable declarations (& thus types) to leak into GMLT, which is undesirable.

Oh.. that was unintentional collateral damage. Thanks for noticing!

echristo requested changes to this revision.Apr 11 2017, 1:48 PM

Sounds like Dave is asking for changes so I'll put it down as Request Changes to get it out of my queue. :)

This revision now requires changes to proceed.Apr 11 2017, 1:48 PM
aprantl updated this revision to Diff 95318.Apr 14 2017, 11:40 AM
aprantl edited edge metadata.
aprantl edited the summary of this revision. (Show Details)
aprantl accepted this revision.Apr 27 2017, 1:50 PM

I think I may haved screwed up the phabricator process for this one.
This landed as r300523.

This revision now requires changes to proceed.Apr 27 2017, 1:50 PM
aprantl abandoned this revision.May 12 2017, 8:05 PM