jdoerfert added a comment.

In D70366#1972880 <https://reviews.llvm.org/D70366#1972880>, @LevitatingLion 
wrote:

> 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?


I don't see a reason why we couldn't.

> 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.

I would prefer the above solution instead of another "stop token".


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

https://reviews.llvm.org/D70366



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to