While I agree with this - it wasn’t the prevailing opinion last time I brought this up (at least for the IR attribute - though I think at least we were all in agreement that it should be the behavior for the clang source attribute): Revisiting/refining the definition of optnone with interprocedural transformations - #38 by jdoerfert
Hmm… yep, that was apparently documented in the original implementation/version (I thought that might’ve been added due to/after my clarifying discussion thread linked above)… which I guess adds some weight to other people’s understanding of the attribute.
Though the “optnone must go with noinline” and various patches that did inhibit interprocedural optimizations in the presence of optnone (I think Chandler at least committed one such patch) certainly points to some confusion/mixed understanding.
I do think adding noipa, removing noinline requirement for optnone (maybe renaming optnone to nointraopt or something - then maybe noipa should be nointeropt to match) and having clang source optnone map to nointeropt+nointraopt would be great. And if folks want to help me dig the ⚙ D101011 [Attr] Add "noipa" function attribute out (either help me justify that changing “isInterposable” should test this property to and we shouldn’t retest/touch every caller - or some help/discussion about how we should go about doing all that efficently and without risking backsliding, etc… - that’d be great)