[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