[PATCH] D101011: [Attr] Add "noipa" function attribute

[Reid Kleckner via Phabricator via llvm-commits]

rnk added a comment.

I agree, this is useful functionality, we should add it.

I would be OK with an all-in-one non-orthogonal `noipa` attribute. The only use case I can come up with for orthogonal attributes is for constructing fine-grained compiler test cases, or trying to carefully convince the optimizer to do one transform or another. The original use case seems more important.

I would also like to suggest another use case for the original attribute, which is that this feature supports hotpatching. If you block IPO across a particular function boundary, you can more reliably recompile and hotpatch in new code, without going to great lengths to break up modules into smaller object files and relinking that way.

In D101011#3383003 <https://reviews.llvm.org/D101011#3383003>, @xbolva00 wrote:

>>> I don't think there's any need for our noipa to differ from GCC's semantics - their documentation that says noipa implies noinline can be seen as a description of behavior, not a constraint on how that behavior is achieved. noipa should logically disable inlining as a consequnce of disallowing interprodecural analysis/information.
>
> GCC’s __attribute__(noipa) (frontend) -> noipa, noinline, noclone, no_icf (midend).

That has some appeal, but what about future optimizations? This supports testability (you can block each transform individually), but it requires frontends to keep track of these unpacked attributes that block all interprocedural optimization. And there's a bitcode auto-upgrade problem: if the frontend intended to block all IPO, how to you upgrade that intention? If you ignore that, you can solve the frontend problem with a utility like `AttrBuilder::addNoIpaAttrs()` which adds all the relevant attributes (noinline, noicf, whatever).

In D101011#3382926 <https://reviews.llvm.org/D101011#3382926>, @dblaikie wrote:

> Sorry I haven't picked this up again. I lost steam when folks suggested that to implement this we could/should revisit/rewrite/retest every call site that checks for interposability... that just doesn't seem productive to me/hard to justify the time to do all that work and doing it partially I think would be really harmful (leaving interposability unaligned/inconsistent with noipa in various subtle ways).
>
> Happy to talk about how we could move this forward perhaps with more hands to do all that work, but I still just don't feel great about that as a direction, really.

I'm sympathetic. :) Are other reviewers mostly concerned with the naming of "derefined" here? I think I agree that the fewer states and special cases we allow, the better, so aligning interposability and noipa is appealing to me.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101011/new/

https://reviews.llvm.org/D101011