[PATCH] D133307: [Assignment Tracking][14/*] Account for assignment tracking in instcombine
Jeremy Morse via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 14 08:03:10 PDT 2022
jmorse requested changes to this revision.
jmorse added a comment.
This revision now requires changes to proceed.
All round good; I've marked one of the questions that I really do have a bit of concern with -- is that a scenario that can actually happen? AFAIUI:
- Store instructions can be duplicated / unrolled as needed by llvm,
- They'll initially have the same DIAssignID,
- The marked code RAUWs the DIAssignID users, which could affect multiple dbg.assigns duplicated with the stores.
The answer to this may well be "no that doesn't happen", analysis appreciated though. Even if it does happen, I imagine that such scenarios are immediately optimised into not existing.
================
Comment at: llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp:274-278
+ auto *FillVal = ConstantInt::get(ITy, Fill);
+ StoreInst *S = Builder.CreateStore(FillVal, Dest, MI->isVolatile());
+ S->copyMetadata(*MI, LLVMContext::MD_DIAssignID);
+ for (auto *DAI : at::getAssignmentMarkers(S))
+ DAI->setValue(FillVal);
----------------
jmorse wrote:
> Is there a risk that, if multiple stores have the same assign ID (which I think is possible?) that other dbg.assign intrinsics down other code paths will have their Values updated?
>
> This might not actually be an issue, because if there's a call to memset (this context) then those parts won't have been promoted to Values.
^
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133307/new/
https://reviews.llvm.org/D133307
More information about the llvm-commits
mailing list