Philip Reames via llvm-dev
2015-Sep-23 18:13 UTC
[llvm-dev] [PATCH] D12923: Add support for function attribute "notail"
On 09/23/2015 08:48 AM, Akira Hatanaka wrote:> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > To be clear, this is a debuging aid only? It's not something > required for correctness? I'm somewhat bothered by that because > it seems like it would be a useful implementation tool for higher > level languages. > > > It's not purely a debugging aid that helps when you are using the > debugger. There are projects (that are not debuggers) that rely on not > missing frames to produce results that are useful.If it's not simply best effort, that constrains our choices.> > A couple of thoughts in no particular order: > 1) Can we always annotate the call site rather than the function? > That removes the unpredictability due to optimization. > > > Annotating the call site should be fine. For the use cases that we > care about, it probably isn't important to prevent tail calls on > indirect calls.Given this, I would lean towards a notail value being added as an alternative to "tail" and "musttail". This seems to fit the existing uses, doesn't have any obvious loop holes or best effort semantics, and solves the problem at hand.> > 2) Calling it something like "no-direct-tail-call" or > "prefer-no-tail" would remove some of the confusion value. When I > see "notail", I expect that to always be respected; the best > effort semantics come as a bit of a surprise. > > > I agree. A name that indicates it's only a best effort option or it's > an option that affects only direct calls would be good.(This only applies if we're talking about a function annotation. The call site annotation applies to both direct and indirect calls.)> > > 3) This seems analogous to the "tail" marker in that it indicates > a preference/option. Whatever we end up with, it needs to be a > verifier option to have a "tail" or "musttail" call site which is > also "notail". It also needs to be an error to have a mustail > callsite to a notail function (if such ends up existing.) > > > If we are going to annotate the function, I think we should have the > verifier catch incompatibilities between the markers on the call sites > and the function attribute on the called functions. > > If we are annotating the call site, the verifier check isn't needed > since the tail-call related markers are enums that are mutually exclusive.Yep.> > 4) It somewhat feels like there are two concepts being intermixed > here. 1) A call site which will never be a tail call. 2) A > function which we prefer not to tail call to. Does it make sense > to separate them? > > > Yes, it makes sense to separate them. For the use case we care about, > either 1) or 2) will do. We don't have to have support for both.I would lean toward doing (1) for now. We can come back and implement (2) at a later time if we find it's needed. After (1), each call site will have four states: - "notail" - Can not be a tail call. - "" - May be a tail call if analysis finds it legal, profitable, and desirable* - "tail" - May be a tail call, profitability hinted - "musttail" - Must be a tail call. * (2) would basically just change the desirability of moving from "" to "tail".> > Philip > > > On 09/21/2015 06:22 PM, Akira Hatanaka wrote: >> Several users have been asking for this function attribute to >> prevent losing the calling functions's information in the >> backtrace. If we attach the attribute to a function, ideally we >> would want to prevent tail call optimization on all call sites >> that call the function. However, the compiler cannot always tell >> which function is called from a call site if it's an indirect >> call, so it's fine if an indirect call to the marked function >> ends up being tail-call optimized. For direct calls, we want the >> function attribute to prevent tail call 100% of the time. >> >> We can also use a "notail" marker on the call instruction instead >> of using a function attribute. The only downside of using a >> marker is that we probably will never be able to prevent tail >> call optimization on indirect calls even when the compiler can >> turn it into a direct call (for example, via inlining). I'm not >> sure at the moment how important this is. >> >> On Thu, Sep 17, 2015 at 9:47 AM, Philip Reames via llvm-commits >> <llvm-commits at lists.llvm.org >> <mailto:llvm-commits at lists.llvm.org>> wrote: >> >> +llvm-dev >> >> Can you give a bit of background on what you're trying to >> address here? After reading through the discussion and >> seeing that this is a best effort flag, I'm not sure that a >> function attribute is the best way to describe this. I'm >> open to being convinced it is, but I'd like to hear a bit >> more about the use case and get broader visibility on the >> proposal first. >> >> Philip >> >> >> On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits wrote: >>> ahatanak created this revision. >>> ahatanak added a subscriber: llvm-commits. >>> >>> This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute. >>> >>> This attribute is different from the existing attribute "disable-tail-calls", which disables tail call optimizations on all call sites within the marked function. >>> >>> The patch to add support for the corresponding source-level function attribute is here: >>> http://reviews.llvm.org/D12922 >>> >>> http://reviews.llvm.org/D12923 >>> >>> Files: >>> docs/LangRef.rst >>> include/llvm/Bitcode/LLVMBitCodes.h >>> include/llvm/IR/Attributes.h >>> include/llvm/IR/Instructions.h >>> lib/AsmParser/LLLexer.cpp >>> lib/AsmParser/LLParser.cpp >>> lib/AsmParser/LLToken.h >>> lib/Bitcode/Reader/BitcodeReader.cpp >>> lib/Bitcode/Writer/BitcodeWriter.cpp >>> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>> lib/IR/Attributes.cpp >>> lib/IR/Verifier.cpp >>> lib/Transforms/Scalar/TailRecursionElimination.cpp >>> test/Bindings/llvm-c/Inputs/invalid.ll.bc >>> test/Bindings/llvm-c/invalid-bitcode.test >>> test/Bitcode/attributes.ll >>> test/Bitcode/invalid.ll >>> test/Bitcode/invalid.ll.bc >>> test/CodeGen/X86/attr-notail.ll >>> test/Transforms/TailCallElim/notail.ll >>> >>> >>> >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> >> >> _______________________________________________ >> llvm-commits mailing list >> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/6fc927e7/attachment-0001.html>
David Majnemer via llvm-dev
2015-Sep-23 18:22 UTC
[llvm-dev] [PATCH] D12923: Add support for function attribute "notail"
I think option #1 would be useful for "correctly" emitting calls to dladdr; it wants to be able to walk up the stack to find what shared object it was called from. On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: > > On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames <listmail at philipreames.com> > wrote: > >> To be clear, this is a debuging aid only? It's not something required >> for correctness? I'm somewhat bothered by that because it seems like it >> would be a useful implementation tool for higher level languages. >> >> > It's not purely a debugging aid that helps when you are using the > debugger. There are projects (that are not debuggers) that rely on not > missing frames to produce results that are useful. > > If it's not simply best effort, that constrains our choices. > > > >> A couple of thoughts in no particular order: >> 1) Can we always annotate the call site rather than the function? That >> removes the unpredictability due to optimization. >> > > Annotating the call site should be fine. For the use cases that we care > about, it probably isn't important to prevent tail calls on indirect calls. > > Given this, I would lean towards a notail value being added as an > alternative to "tail" and "musttail". This seems to fit the existing uses, > doesn't have any obvious loop holes or best effort semantics, and solves > the problem at hand. > > > >> 2) Calling it something like "no-direct-tail-call" or "prefer-no-tail" >> would remove some of the confusion value. When I see "notail", I expect >> that to always be respected; the best effort semantics come as a bit of a >> surprise. >> > > I agree. A name that indicates it's only a best effort option or it's an > option that affects only direct calls would be good. > > (This only applies if we're talking about a function annotation. The call > site annotation applies to both direct and indirect calls.) > > > >> >> 3) This seems analogous to the "tail" marker in that it indicates a >> preference/option. Whatever we end up with, it needs to be a verifier >> option to have a "tail" or "musttail" call site which is also "notail". It >> also needs to be an error to have a mustail callsite to a notail function >> (if such ends up existing.) >> > > If we are going to annotate the function, I think we should have the > verifier catch incompatibilities between the markers on the call sites and > the function attribute on the called functions. > > If we are annotating the call site, the verifier check isn't needed since > the tail-call related markers are enums that are mutually exclusive. > > Yep. > > > >> 4) It somewhat feels like there are two concepts being intermixed here. >> 1) A call site which will never be a tail call. 2) A function which we >> prefer not to tail call to. Does it make sense to separate them? >> >> > Yes, it makes sense to separate them. For the use case we care about, > either 1) or 2) will do. We don't have to have support for both. > > I would lean toward doing (1) for now. We can come back and implement (2) > at a later time if we find it's needed. After (1), each call site will > have four states: > - "notail" - Can not be a tail call. > - "" - May be a tail call if analysis finds it legal, profitable, and > desirable* > - "tail" - May be a tail call, profitability hinted > - "musttail" - Must be a tail call. > > * (2) would basically just change the desirability of moving from "" to > "tail". > > > Philip >> >> >> On 09/21/2015 06:22 PM, Akira Hatanaka wrote: >> >> Several users have been asking for this function attribute to prevent >> losing the calling functions's information in the backtrace. If we attach >> the attribute to a function, ideally we would want to prevent tail call >> optimization on all call sites that call the function. However, the >> compiler cannot always tell which function is called from a call site if >> it's an indirect call, so it's fine if an indirect call to the marked >> function ends up being tail-call optimized. For direct calls, we want the >> function attribute to prevent tail call 100% of the time. >> >> We can also use a "notail" marker on the call instruction instead of >> using a function attribute. The only downside of using a marker is that we >> probably will never be able to prevent tail call optimization on indirect >> calls even when the compiler can turn it into a direct call (for example, >> via inlining). I'm not sure at the moment how important this is. >> >> On Thu, Sep 17, 2015 at 9:47 AM, Philip Reames via llvm-commits < >> <llvm-commits at lists.llvm.org>llvm-commits at lists.llvm.org> wrote: >> >>> +llvm-dev >>> >>> Can you give a bit of background on what you're trying to address here? >>> After reading through the discussion and seeing that this is a best effort >>> flag, I'm not sure that a function attribute is the best way to describe >>> this. I'm open to being convinced it is, but I'd like to hear a bit more >>> about the use case and get broader visibility on the proposal first. >>> >>> Philip >>> >>> >>> On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits wrote: >>> >>> ahatanak created this revision. >>> ahatanak added a subscriber: llvm-commits. >>> >>> This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute. >>> >>> This attribute is different from the existing attribute "disable-tail-calls", which disables tail call optimizations on all call sites within the marked function. >>> >>> The patch to add support for the corresponding source-level function attribute is here:http://reviews.llvm.org/D12922 >>> http://reviews.llvm.org/D12923 >>> >>> Files: >>> docs/LangRef.rst >>> include/llvm/Bitcode/LLVMBitCodes.h >>> include/llvm/IR/Attributes.h >>> include/llvm/IR/Instructions.h >>> lib/AsmParser/LLLexer.cpp >>> lib/AsmParser/LLParser.cpp >>> lib/AsmParser/LLToken.h >>> lib/Bitcode/Reader/BitcodeReader.cpp >>> lib/Bitcode/Writer/BitcodeWriter.cpp >>> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>> lib/IR/Attributes.cpp >>> lib/IR/Verifier.cpp >>> lib/Transforms/Scalar/TailRecursionElimination.cpp >>> test/Bindings/llvm-c/Inputs/invalid.ll.bc >>> test/Bindings/llvm-c/invalid-bitcode.test >>> test/Bitcode/attributes.ll >>> test/Bitcode/invalid.ll >>> test/Bitcode/invalid.ll.bc >>> test/CodeGen/X86/attr-notail.ll >>> test/Transforms/TailCallElim/notail.ll >>> >>> >>> >>> >>> _______________________________________________ >>> llvm-commits mailing listllvm-commits at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >>> >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >> >> > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150923/50bf1a68/attachment.html>
Akira Hatanaka via llvm-dev
2015-Sep-24 20:47 UTC
[llvm-dev] [PATCH] D12923: Add support for function attribute "notail"
On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames <listmail at philipreames.com> wrote:> > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: > > On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames <listmail at philipreames.com> > wrote: > >> To be clear, this is a debuging aid only? It's not something required >> for correctness? I'm somewhat bothered by that because it seems like it >> would be a useful implementation tool for higher level languages. >> >> > It's not purely a debugging aid that helps when you are using the > debugger. There are projects (that are not debuggers) that rely on not > missing frames to produce results that are useful. > > If it's not simply best effort, that constrains our choices. > > > >> A couple of thoughts in no particular order: >> 1) Can we always annotate the call site rather than the function? That >> removes the unpredictability due to optimization. >> > > Annotating the call site should be fine. For the use cases that we care > about, it probably isn't important to prevent tail calls on indirect calls. > > Given this, I would lean towards a notail value being added as an > alternative to "tail" and "musttail". This seems to fit the existing uses, > doesn't have any obvious loop holes or best effort semantics, and solves > the problem at hand. > > > >> 2) Calling it something like "no-direct-tail-call" or "prefer-no-tail" >> would remove some of the confusion value. When I see "notail", I expect >> that to always be respected; the best effort semantics come as a bit of a >> surprise. >> > > I agree. A name that indicates it's only a best effort option or it's an > option that affects only direct calls would be good. > > (This only applies if we're talking about a function annotation. The call > site annotation applies to both direct and indirect calls.) > > > >> >> 3) This seems analogous to the "tail" marker in that it indicates a >> preference/option. Whatever we end up with, it needs to be a verifier >> option to have a "tail" or "musttail" call site which is also "notail". It >> also needs to be an error to have a mustail callsite to a notail function >> (if such ends up existing.) >> > > If we are going to annotate the function, I think we should have the > verifier catch incompatibilities between the markers on the call sites and > the function attribute on the called functions. > > If we are annotating the call site, the verifier check isn't needed since > the tail-call related markers are enums that are mutually exclusive. > > Yep. > > > >> 4) It somewhat feels like there are two concepts being intermixed here. >> 1) A call site which will never be a tail call. 2) A function which we >> prefer not to tail call to. Does it make sense to separate them? >> >> > Yes, it makes sense to separate them. For the use case we care about, > either 1) or 2) will do. We don't have to have support for both. > > I would lean toward doing (1) for now. We can come back and implement (2) > at a later time if we find it's needed. After (1), each call site will > have four states: > - "notail" - Can not be a tail call. > - "" - May be a tail call if analysis finds it legal, profitable, and > desirable* > - "tail" - May be a tail call, profitability hinted > - "musttail" - Must be a tail call. > > * (2) would basically just change the desirability of moving from "" to > "tail". > >OK. I'm considering changing the direction of this patch and marking the call site instead of the called function. We should also discuss what kinds of source level attributes we'll need. My plan is to attach an attribute that indicates notail (something like no_direct_tail) to the called function declaration and definition and then mark all the direct call sites in the IR that call the function as notaill. In addition to that, it seems like we want to have a way to attach the attribute directly to the call site: void (*indirectCall)(int, int, int); void foo1(int a, int b) { (*indirectCall)(a, b, c) __attribute__((notail)); }> > Philip >> >> >> On 09/21/2015 06:22 PM, Akira Hatanaka wrote: >> >> Several users have been asking for this function attribute to prevent >> losing the calling functions's information in the backtrace. If we attach >> the attribute to a function, ideally we would want to prevent tail call >> optimization on all call sites that call the function. However, the >> compiler cannot always tell which function is called from a call site if >> it's an indirect call, so it's fine if an indirect call to the marked >> function ends up being tail-call optimized. For direct calls, we want the >> function attribute to prevent tail call 100% of the time. >> >> We can also use a "notail" marker on the call instruction instead of >> using a function attribute. The only downside of using a marker is that we >> probably will never be able to prevent tail call optimization on indirect >> calls even when the compiler can turn it into a direct call (for example, >> via inlining). I'm not sure at the moment how important this is. >> >> On Thu, Sep 17, 2015 at 9:47 AM, Philip Reames via llvm-commits < >> <llvm-commits at lists.llvm.org>llvm-commits at lists.llvm.org> wrote: >> >>> +llvm-dev >>> >>> Can you give a bit of background on what you're trying to address here? >>> After reading through the discussion and seeing that this is a best effort >>> flag, I'm not sure that a function attribute is the best way to describe >>> this. I'm open to being convinced it is, but I'd like to hear a bit more >>> about the use case and get broader visibility on the proposal first. >>> >>> Philip >>> >>> >>> On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits wrote: >>> >>> ahatanak created this revision. >>> ahatanak added a subscriber: llvm-commits. >>> >>> This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute. >>> >>> This attribute is different from the existing attribute "disable-tail-calls", which disables tail call optimizations on all call sites within the marked function. >>> >>> The patch to add support for the corresponding source-level function attribute is here:http://reviews.llvm.org/D12922 >>> http://reviews.llvm.org/D12923 >>> >>> Files: >>> docs/LangRef.rst >>> include/llvm/Bitcode/LLVMBitCodes.h >>> include/llvm/IR/Attributes.h >>> include/llvm/IR/Instructions.h >>> lib/AsmParser/LLLexer.cpp >>> lib/AsmParser/LLParser.cpp >>> lib/AsmParser/LLToken.h >>> lib/Bitcode/Reader/BitcodeReader.cpp >>> lib/Bitcode/Writer/BitcodeWriter.cpp >>> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>> lib/IR/Attributes.cpp >>> lib/IR/Verifier.cpp >>> lib/Transforms/Scalar/TailRecursionElimination.cpp >>> test/Bindings/llvm-c/Inputs/invalid.ll.bc >>> test/Bindings/llvm-c/invalid-bitcode.test >>> test/Bitcode/attributes.ll >>> test/Bitcode/invalid.ll >>> test/Bitcode/invalid.ll.bc >>> test/CodeGen/X86/attr-notail.ll >>> test/Transforms/TailCallElim/notail.ll >>> >>> >>> >>> >>> _______________________________________________ >>> llvm-commits mailing listllvm-commits at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >>> >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150924/e328b38a/attachment.html>
Philip Reames via llvm-dev
2015-Sep-24 20:53 UTC
[llvm-dev] [PATCH] D12923: Add support for function attribute "notail"
On 09/24/2015 01:47 PM, Akira Hatanaka wrote:> On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: >> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames >> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: >> >> To be clear, this is a debuging aid only? It's not something >> required for correctness? I'm somewhat bothered by that >> because it seems like it would be a useful implementation >> tool for higher level languages. >> >> >> It's not purely a debugging aid that helps when you are using the >> debugger. There are projects (that are not debuggers) that rely >> on not missing frames to produce results that are useful. > If it's not simply best effort, that constrains our choices. >> >> A couple of thoughts in no particular order: >> 1) Can we always annotate the call site rather than the >> function? That removes the unpredictability due to optimization. >> >> >> Annotating the call site should be fine. For the use cases that >> we care about, it probably isn't important to prevent tail calls >> on indirect calls. > Given this, I would lean towards a notail value being added as an > alternative to "tail" and "musttail". This seems to fit the > existing uses, doesn't have any obvious loop holes or best effort > semantics, and solves the problem at hand. >> >> 2) Calling it something like "no-direct-tail-call" or >> "prefer-no-tail" would remove some of the confusion value. >> When I see "notail", I expect that to always be respected; >> the best effort semantics come as a bit of a surprise. >> >> >> I agree. A name that indicates it's only a best effort option or >> it's an option that affects only direct calls would be good. > (This only applies if we're talking about a function annotation. > The call site annotation applies to both direct and indirect calls.) >> >> >> 3) This seems analogous to the "tail" marker in that it >> indicates a preference/option. Whatever we end up with, it >> needs to be a verifier option to have a "tail" or "musttail" >> call site which is also "notail". It also needs to be an >> error to have a mustail callsite to a notail function (if >> such ends up existing.) >> >> >> If we are going to annotate the function, I think we should have >> the verifier catch incompatibilities between the markers on the >> call sites and the function attribute on the called functions. >> >> If we are annotating the call site, the verifier check isn't >> needed since the tail-call related markers are enums that are >> mutually exclusive. > Yep. >> >> 4) It somewhat feels like there are two concepts being >> intermixed here. 1) A call site which will never be a tail >> call. 2) A function which we prefer not to tail call to. >> Does it make sense to separate them? >> >> >> Yes, it makes sense to separate them. For the use case we care >> about, either 1) or 2) will do. We don't have to have support for >> both. > I would lean toward doing (1) for now. We can come back and > implement (2) at a later time if we find it's needed. After (1), > each call site will have four states: > - "notail" - Can not be a tail call. > - "" - May be a tail call if analysis finds it legal, profitable, > and desirable* > - "tail" - May be a tail call, profitability hinted > - "musttail" - Must be a tail call. > > * (2) would basically just change the desirability of moving from > "" to "tail". > > > OK. I'm considering changing the direction of this patch and marking > the call site instead of the called function. > > We should also discuss what kinds of source level attributes we'll > need. My plan is to attach an attribute that indicates notail > (something like no_direct_tail) to the called function declaration and > definition and then mark all the direct call sites in the IR that call > the function as notaill. In addition to that, it seems like we want to > have a way to attach the attribute directly to the call site: > > void (*indirectCall)(int, int, int); > > void foo1(int a, int b) { > (*indirectCall)(a, b, c) __attribute__((notail)); > }I think you're going to want to have the same dichotomy between (1) and (2) at the source level as in the IR. The same issues apply in both cases.> >> >> Philip >> >> >> On 09/21/2015 06:22 PM, Akira Hatanaka wrote: >>> Several users have been asking for this function attribute >>> to prevent losing the calling functions's information in the >>> backtrace. If we attach the attribute to a function, ideally >>> we would want to prevent tail call optimization on all call >>> sites that call the function. However, the compiler cannot >>> always tell which function is called from a call site if >>> it's an indirect call, so it's fine if an indirect call to >>> the marked function ends up being tail-call optimized. For >>> direct calls, we want the function attribute to prevent tail >>> call 100% of the time. >>> >>> We can also use a "notail" marker on the call instruction >>> instead of using a function attribute. The only downside of >>> using a marker is that we probably will never be able to >>> prevent tail call optimization on indirect calls even when >>> the compiler can turn it into a direct call (for example, >>> via inlining). I'm not sure at the moment how important this is. >>> >>> On Thu, Sep 17, 2015 at 9:47 AM, Philip Reames via >>> llvm-commits <llvm-commits at lists.llvm.org >>> <mailto:llvm-commits at lists.llvm.org>> wrote: >>> >>> +llvm-dev >>> >>> Can you give a bit of background on what you're trying >>> to address here? After reading through the discussion >>> and seeing that this is a best effort flag, I'm not sure >>> that a function attribute is the best way to describe >>> this. I'm open to being convinced it is, but I'd like to >>> hear a bit more about the use case and get broader >>> visibility on the proposal first. >>> >>> Philip >>> >>> >>> On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits >>> wrote: >>>> ahatanak created this revision. >>>> ahatanak added a subscriber: llvm-commits. >>>> >>>> This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute. >>>> >>>> This attribute is different from the existing attribute "disable-tail-calls", which disables tail call optimizations on all call sites within the marked function. >>>> >>>> The patch to add support for the corresponding source-level function attribute is here: >>>> http://reviews.llvm.org/D12922 >>>> >>>> http://reviews.llvm.org/D12923 >>>> >>>> Files: >>>> docs/LangRef.rst >>>> include/llvm/Bitcode/LLVMBitCodes.h >>>> include/llvm/IR/Attributes.h >>>> include/llvm/IR/Instructions.h >>>> lib/AsmParser/LLLexer.cpp >>>> lib/AsmParser/LLParser.cpp >>>> lib/AsmParser/LLToken.h >>>> lib/Bitcode/Reader/BitcodeReader.cpp >>>> lib/Bitcode/Writer/BitcodeWriter.cpp >>>> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp >>>> lib/IR/Attributes.cpp >>>> lib/IR/Verifier.cpp >>>> lib/Transforms/Scalar/TailRecursionElimination.cpp >>>> test/Bindings/llvm-c/Inputs/invalid.ll.bc >>>> test/Bindings/llvm-c/invalid-bitcode.test >>>> test/Bitcode/attributes.ll >>>> test/Bitcode/invalid.ll >>>> test/Bitcode/invalid.ll.bc >>>> test/CodeGen/X86/attr-notail.ll >>>> test/Transforms/TailCallElim/notail.ll >>>> >>>> >>>> >>>> _______________________________________________ >>>> llvm-commits mailing list >>>> llvm-commits at lists.llvm.org >>>> <mailto:llvm-commits at lists.llvm.org> >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >>> _______________________________________________ >>> llvm-commits mailing list >>> llvm-commits at lists.llvm.org >>> <mailto:llvm-commits at lists.llvm.org> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits >>> >>> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150924/5371708a/attachment.html>