dwblaikie wrote: I think
> > The _effect_ this has is certainly desirable, but I'm not sure this is the > > way to implement it. There was a recent PR (#211804) that excluded > > signature changes from optnone. In there, I was arguing that we should > > really be treating optnone the same as noipa in the first place (i.e. > > basically as an interposable function). > > That was certainly my original thesis (at the start of > https://discourse.llvm.org/t/revisiting-refining-the-definition-of-optnone-with-interprocedural-transformations/58095) > - that `optnone` should behave as if the function definition wasn't > available/were in another module compiled at -O0. This was consistent with > @pogo59 's original design intent when he proposed and implemented `optnone`, > and various other folks understanding along the way. > > Bunch of folks ( @fhahn @jdoerfert @LebedevRI ) had what seemed a fairly > strong preference to separate `noipa` and `optnone`, at least at the IR level > (where `optnone` would mean "don't make optimization changes to the body of > the function" and `noipa` would mean "don't make optimizations to > callers/other functions on the basis of examining the body of this function") > & so things went in that direction. > > @nikic + dissenters - if you folks are happy to come to the conclusion that > IR `optnone` implies `noipa` I'm totally happy (happier in fact than this > direction of implementing it in clang) to go in that direction (it might be > marginally easier for that to be implemented in practice by requiring that > `noipa` be applied wherever `optnone` is, though? (rather than having every > place that checks `noipa` also check `optnone` - though I guess we can go > write a helper function so hopefully we never check `noipa` without also > checking `optnone`) - the same way I think currently `optnone` requires > `noinline` maybe... ) Ping on this? if we implement "optnone implies noipa" the same way "optnone implies noinline" (which is to say, really, "optnone /requires/ noinline" and "optnone /requires/ noipa") then actually this change is the right one to make - adding optnone when we add noipa, then as a follow-on we can change LLVM to require it, without breaking clang (because clang'll already be meeting that requirement). Or do you, @nikic, feel strongly about revisiting that implies-implemented-as-requires, and instead having LLVM check both the optnone and noipa attributes, and having clang only set optnone (possibly doing this with noinline too? otherwise it's inconsistent) https://github.com/llvm/llvm-project/pull/218782 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
