[PATCH] D70366: Add new 'flatten' LLVM attribute to fix clang's 'flatten' function attribute

[LevitatingLion via Phabricator via cfe-commits]

LevitatingLion added a comment.

In D70366#1971137 <https://reviews.llvm.org/D70366#1971137>, @dexonsmith wrote:

> In D70366#1970758 <https://reviews.llvm.org/D70366#1970758>, @jdoerfert wrote:
>
> > In D70366#1970526 <https://reviews.llvm.org/D70366#1970526>, @dexonsmith wrote:
> >
> > > In D70366#1970299 <https://reviews.llvm.org/D70366#1970299>, @LevitatingLion wrote:
> > >
> > > > Maybe we can add an additional string attribute when adding the noinline attribute to functions which are not marked noinline in the source code, something like "noinline-added-by-clang". I don't know if that's a legitimate use case for a string attribute, but it wouldn't be very invasive. What do you think?
> > >
> > >
> > > Another option (not sure if it's better) would be to add a `noopt` LLVM attribute that Clang adds for `-O0` instead of `noinline`.  Two possibilities would be to update the inliner to pay attention to that as well (with special logic for `flatten`), or to change the always-inliner to add `noinline` to anything marked `noopt`.
> >
> >
> > `noopt == optnone`? Both `optnone` and `noinline` are set in O0, so we could just not place `noinline` (I think).
>
>
> Sure, that could work.  Or the noflatten idea is another possibility.  It would be good to hear what others think.


`optnone` currently requires `noinline`. Can we simply remove this requirement or would that need more changes?

If I understand the `noflatten` idea correctly, we would change the LLVM behaviour so that `alwaysinline_recursively` ignores `noinline` and stops inlining only when a callee has a dedicated "stop-marker" attribute (e.g. `noflatten`)? I think that would be counter-intuitive, `noinline` should prevent inlining.


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

https://reviews.llvm.org/D70366