I’ve updated D101011 to do something more or less like where I started, but renaming the mayBeDerefined to mayBeDerefinedOrNoIPA. (though I wonder - what would happen if we sunk this further and renamed isInterposable to isInterposableOrNoIPA? But I won’t insist on that - I’d rather move forward with something here than struggle too much more).
Would love to get some more visibility on the review/see if we can move that forward.
(& picking up from the end of the last thread, in case that’s helpful)
Ah, OK - I still think of that as noipa. Like if this function were defined in some precompiled object - we could still perform these optimizations/analyses if the function declaration had the attributes where we are optimizing. We didn’t analyze some other function definition…
Eh, it’s probably not a helpful discussion - however we want to describe this situation, I think it’s good/OK. Maybe clang should avoid putting function attributes on functions it’s generating with noipa but, again, happy to discuss that as a clang issue/bug/whatever.
Yeah, I don’t want that.
But maybe I’ll want this. Might depend on the attributes - but I’m happy with that being a clang problem, not an LLVM problem.
I think the simplest model is “as if this function body weren’t available for analysis - the same behavior as if you precompiled this into some other object file without LTO, etc”.
That is still not deciding the sticky point here. As you mentioned above:
What I’m getting at is that “precompiled object”, or “no function body available”, do not exclude us from using attributes (implicitly) across the call boundary (=interprocedurally). That said, I’m happy with us saying: noipa allows transformations for which the body would not be required to be part of the TU, or better wording for it, but that does not prevent “all ipa”, including the examples that I’ve shown before.