similar to: [PATCH] D12923: Add support for function attribute "notail"

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. 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. 2) Calling

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

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

On 09/24/2015 03:04 PM, Akira Hatanaka wrote: > On Thu, Sep 24, 2015 at 1:53 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > 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

I've been discussing the clang-side patch and making changes based on the feedback I got for the last few weeks. Aaron has reviewed the patch and he thinks it's OK now. http://reviews.llvm.org/D12922 Do you have further comments on the llvm-side patch or the semantics of the function attribute? Since the last time we discussed on the list, I've made changes to disallow virtual

On Tue, Sep 29, 2015 at 10:49 AM, Philip Reames <listmail at philipreames.com> wrote: > > > On 09/28/2015 10:38 PM, Sanjoy Das wrote: > >> >> > That was what I had in mind: the function attribute blocks tail call >> for statically direct calls but doesn't promise >> > anything (in fact, does nothing) for indirect calls. >> > >>

> That was what I had in mind: the function attribute blocks tail call for statically direct calls but doesn't promise > anything (in fact, does nothing) for indirect calls. > > Do you think we shouldn't make any promises for statically direct calls either? I don't see why it's hard to keep the > promise that direct tail calls will be blocked. Do you have a

On 2020-05-08 1:34 p.m., Xun Li wrote: > Hi, > > I was looking into the implementation of TailRecursionElimination, and > noticed that we have the constrain that if any call uses a local, even > though it doesn't capture the local, it would still prohibit TCE. This > contain seems unnecessary and overly limiting? I think it's a necessary limitation. The idea is that

On 2020-05-08 2:58 p.m., Xun Li wrote: > Eli, > Yes I was referring to AllCallsAreTailCalls. I will take a look at how > to improve this. > > Nick, > Thanks. I agree that's the proper constrain to mark a call as > tailcall, however not being able to mark a call as tailcall shouldn't > completely kill TCE. (i.e. AllCallsAreTailCalls seems overly > limiting). I

Hi, I was looking into the implementation of TailRecursionElimination, and noticed that we have the constrain that if any call uses a local, even though it doesn't capture the local, it would still prohibit TCE. This contain seems unnecessary and overly limiting? Relevant code is here:

[Adding llvm-dev and re-stating the situation for llvm-dev's benefit] *RFC: A new attribute, "norecurse".* In some cases, it is possible to demote global variables to local variables. This is possible when the global is only used in one function, and that function is known not to recurse (because if the function recurses, a local variable cannot be equivalent to a global as the

Hi Aaron, I think it must necessarily be exposed to users - clang must add it in certain circumstances for example. I don't think this is particularly different to many other attributes such as nocapture/nounwind, that are exposed to users and can be set by users in exceptional circumstances but are primarily inferred by the midend. James On Thu, 5 Nov 2015 at 16:03 Aaron Ballman <aaron

Ah I see. I can't think of a way that would help users in any particular way offhand. I hadn't considered exposing it to clang users - do you think there is merit in that? James On Thu, 5 Nov 2015 at 16:08 Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Nov 5, 2015 at 11:06 AM, James Molloy <james at jamesmolloy.co.uk> > wrote: > > Hi Aaron, > >

Hi Alex, We've only recently managed to get the core scalable vector IR type into the codebase (so it will be present in 9.0); that allows you to write IR with scalable vector types, but there's no backend able to generate code for it yet, and as you mention no support for stepvector (or vscale). Arm will start upstreaming those soon. -Graham > On 13 Jul 2019, at 14:32, Alex Susu via

I had a phone conversation yesterday with Graham, Francesco, and Kristof. There is one more reason to go with the native type change: ARM has already written the code with the SV types, and they have patches ready to be reviewed and integrated in LLVM. As I don't want to stand in the way of getting SVE in LLVM as soon as possible, I will also support the integration of the existing patches

Hello; I wanted to insert two new terminator instructions in LLVM IR. I modified the necessary files (as mentioned in the tutorial in LLVM site and some more to meet the new structure of LLVM, (e.g no Lexer.l now, we have LLLexer.cpp. Again in the tutorial, files like LLVMBitCodes.h, include/llvm-c/core.h that need to be modified are not mentioned) But I am getting the error while building

Hello everyone! I've recently had a chance to familiarize myself with the nitty-gritty details of LLVM IR. It has been a great learning experience, sometimes frustrating or confusing but mostly rewarding. There are a few cases I've come across which seems odd to me. I've tried to cross reference with the language specification and the source code to the best of my abilities, but

Hello Sean, Thank you for your reply. I'll give your suggestion to item 6 and 7 a try tonight. I'll start a compilation and let it run throughout the night. My laptop (x61s) is 8 years old by know, so compiling LLVM takes a little time :) Regarding item 8. I don't know if anyone is using "": in the wild so fixing the implementation might make sense. If not the

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH]

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >>