Noipa continues

[dblaikie]

Picking up from previous discussions/reviews:

Revisiting/refining the definition of optnone with interprocedural transformations

While trying to reproduce some debug info thing (I don’t have the exact example at the moment - but I think it was more aggressive than the example I have now, but something like this: attribute((optnone)) int f1() { return 3; } int main() { return f1(); } (actually I think in my case I had a variable to hold the return value from f1, with the intent that this variable’s location couldn’t use a constant - a load from a volatile variable would probably have provided similar functionality…

https://reviews.llvm.org/D101011

Force optimizations even when optnone is present

It won’t? Oh, if we do the “noipa allows attribute deduction and usage” - then, yes, we’d eliminate side-effect free calls. But I don’t think we should do that (we could either allow attribute deduction, but interprocedural analyses would have to explicitly notice noipa and ignore all other attributes - or we don’t allow deduction and IPA works naturally/only uses attributes explicitly provided alongside the noipa). So, your proposal to (re)use derefined will use the attributes that comes wi…

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)

@jdoerfert

@dblaikie

I remember people being upset we removed side-effect free calls even if the callee was optnone. Checking noipa only in the maybe derefined query will not help this case (not that I care too much).

It won’t? Oh, if we do the “noipa allows attribute deduction and usage” - then, yes, we’d eliminate side-effect free calls. But I don’t think we should do that (we could either allow attribute deduction, but interprocedural analyses would have to explicitly notice noipa and ignore all other attributes - or we don’t allow deduction and IPA works naturally/only uses attributes explicitly provided alongside the noipa).

So, your proposal to (re)use derefined will use the attributes that comes with noipa. We can avoid adding new ones (as we do for maybe derefined already), but the odd cases where the input has noipa and other attributes are still “not really noipa”.

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.

If you want no-ipa mean to not look at attributes

Yeah, I don’t want that.

(2) tell the frontends to not emit/drop attributes if they emit noipa functions (also not perfect but I like it better).

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.

If you want it to mean: do not infer new attributes, your proposal is fine as is.
I am OK either way, I think, but we need to document it properly. As it is now, it does not mean “no-ipa” means no interprocedural reasoning, it just means something like no(t much) “additional” interprocedural reasoning.

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”.

[jdoerfert]

@dblaikie

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:

@dblaikie

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…

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.

[dblaikie]

sure - I’m down with that/I think it’s suitable/good/fine and I’ve documented it as such in DR101011