dwblaikie wrote: > 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... ) https://github.com/llvm/llvm-project/pull/218782 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
