[PATCH] D41104: Set the NoRecurse attribute for the dbg intrinsics.
Hal Finkel via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Dec 21 09:55:17 PST 2017
hfinkel added a comment.
In https://reviews.llvm.org/D41104#958640, @efriedma wrote:
>
> This isn't what LangRef says, and it would be kind of hard to nail down a definition which actually works like this. I mean, I guess you could try to define it in terms of the callgraph, but that would have unusual implications. (What happens if your program contains a call which is dynamically dead, and incorrectly marked norecurse?)
I agree. We shouldn't define this based only on the static call graph. It should be a dynamic property (like, essentially, everything else in order to avoid the dead-code-changing-semantics issue). It seems like we screwed this up a bit because the inference logic in FunctionAttrs won't clearly do the right thing in such cases (and it can't, because norecurse doesn't really have the right semantic information).
> We probably want a new attribute to express the relevant property, which is essentially that most intrinsics don't call any function defined in your program.
That works.
> I guess...? I don't like proposing new attributes, but I don't see an alternative. (Granted, it could get a little tricky to define precisely what the attribute means given that our runtime functions are written in C.)
I think that we'd do this in a similar way to how we define our inaccessiblememonly attribute. You'd say that calling the function will not, directly or indirectly, call any function in the module being compiled.
> If you just want to fix the debuginfo issue, you could just check specifically for debuginfo intrinsics in the FunctionAttrs pass; we treat them specially in many passes.
I think that we can easily do better by calling TTI->isLoweredToCall(F), and ignoring everything for which this is false (which will be for the debug intrinsics, and also for a bunch of other things).
https://reviews.llvm.org/D41104
More information about the llvm-commits
mailing list