[PATCH] D75815: [InstCombine] Simplify calls with "returned" attribute

[Roman Lebedev via Phabricator via llvm-commits]

lebedev.ri added a subscriber: chandlerc.
lebedev.ri added a comment.

In D75815#1943589 <https://reviews.llvm.org/D75815#1943589>, @glider wrote:

> > Yeah, like i said, `noinline` is insufficient here, and i don't actually
> >  think we currently have the right tool to block any such transform:
>
> Do you think it makes sense to check for noinline before transforming the call into the argument, i.e.:
>
>   if (!Call.use_empty() && !Call.isMustTailCall()) {
>     Function *Fn = dyn_cast<Function>(Callee);
>     if (Fn && Fn->hasFnAttribute(Attribute::NoInline))
>       if (Value *ReturnedArg = Call.getReturnedArgOperand())
>         return replaceInstUsesWith(Call, ReturnedArg);
>   }
>   


I can only once again point at

In D53431#1271272 <https://reviews.llvm.org/D53431#1271272>, @chandlerc wrote:

> The intent of `noinline` in LLVM's IR is to block inlining, not all interprocedural optimizations. So I don't think this is actually a bug and don't think this patch should be applied.
>
> We have an attribute to block optimizations: `optnone`.




In D75815#1943589 <https://reviews.llvm.org/D75815#1943589>, @glider wrote:

> >> You're right, we'll have to write them down. But in the case of noinline attribute langref is pretty clear on this subject: "This attribute indicates that the inliner should never inline this function in any situation."
> > 
> > To be noted, i'm not currently saying that the expected behavior is unreasonable,
> >  i'm merely saying that the behavior was not actually guaranteed but accidental,
> >  and likely partial.
>
> I agree. Let's concentrate on noinline then, as we can afford making our attributes imply noinline.


I'm guessing s/can/can't/ was meant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75815