similar to: Noncapture use of locals disabling TailRecursionElimination

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 all, this (altough a big patch) is actually pretty straight forward: It (tries) to preserve ProfileInfo in all -std-compile-opts passes and all X86-Backend passes. There is still some passes that have corner cases where the ProfileInfo is not correct after the pass. Some passes are still missing... How shall I proceed with this? Andi -------------- next part -------------- A non-text

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

Hello, Here are a few misc. comments on this patch. Would it make sense to mark the ProfileInfo passes as "CFGOnly?" If so, that would let them be automatically preserved by passes which don't modify the CFG (and that call AU.setPreservesCFG()). > + if (ProfileInfo* PI = getAnalysisIfAvailable<ProfileInfo>()) { > + PI->splitEdge(OrigPreHeader, NewHeader,

Hi devels, there are two issues concerning invoking optimizations: 1. this document: http://llvm.cs.uiuc.edu/docs/GettingStarted.html is very nice, it would be good though to add in a section An Example Using the LLVM Tool Chain examples on optimization step. 2. If i am not wrong there is no tool, which integrates all steps: llvmgcc->opt->llc into something like llcc (and

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

Hi Hal, > As we had briefly mentioned on IRC, one way of forming this 'stack', and its associated 'cnt' variable, is to use dynamic stack allocation. I hadn't really reached a decision on the mechanics yet. However, your suggestion while it can work within the current abilities of the IR, has the disadvantage that it is using an extra stack slot for the link pointer. I

On Sat, 1 May 2004, [koi8-r] "Valery A.Khamenya[koi8-r] " wrote: > there are two issues concerning invoking optimizations: > > 1. > this document: > http://llvm.cs.uiuc.edu/docs/GettingStarted.html > is very nice, it would be good though to add in a section > > An Example Using the LLVM Tool Chain > > examples on optimization step. That's an

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

Hi, The other day on IRC myself, Chandler, Hal and Pablo discussed recursive inlining. I've pondered a bit since then, and thought I'd get some background on the list with the aim of stimulating discussion. Our goal is to inline recursive functions. We have several workloads with recursive calls, and inlining them to a certain degree can improve performance by up to 30%. Inlining

Hi, Guys: I'm new for LLVM. Just downloaded the LLVM. I used cmake to compiler the LLVM3.3, but found an error, because it can not automatically compiler the target description file (*.td) to the .inc file. But when I tried the LLVM 3.2, It is ok. Could your give me some suggestion? Regards' Xun -------------- next part -------------- An HTML attachment was scrubbed... URL:

The documentation is correct, and the observation that the IR verifier is currently not verifying this property is also correct. Due to the way that dbg.declares are handled by later stages, LLVM can only keep track of one dbg.declare per variable and that is intentional. The dbg.declare intrinsic is supposed to pin a variable to a stack slot, such as in the code that clang emits at -O0. If you

Hi, In the LLVM documentation it says "there can only be one call to llvm.dbg.declare for a given concrete local variable." However we don't seem to be checking it. opt tool can process IR that violates this rule without complaining. Is this intended, or is it a bug? What would be the consequence when this constraint is broken? -- Xun

Hi Xun, On 16/09/13 03:42, Xun Chen wrote: > Hi, Guys: > > I'm new for LLVM. Just downloaded the LLVM. > I used cmake to compiler the LLVM3.3, but found an error, because it can > not automatically compiler the target description file (*.td) to the .inc file. > But when I tried the LLVM 3.2, It is ok. > Could your give me some suggestion? your description

Hi All, I am working on a custom defined architecture which implements Sparc ISA but without floating point instructions. I have two questions regarding using LLVM: 1. How to enable soft-float when building llvm-gcc? 2. How to let llvm-gcc generate native code (binaries) for Sparc? Do I have to compile glibc or newlib for Sparc and link with it together? I am kinda confused so it would be great

Hi, Apologies for the very late response. We have manually tried the idea with a very simple Fibonacci sequence code. While being very very simple, the recursion cannot be handled by TRE. Because there are two recursive callsites, it also needs to keep some sort of state across iterations of the "while(stack not empty)" loop. We get between 2.5 and 8x slowdowns depending on which

While working on the printing code, my colleague Zbyn?k ?lajchrt noticed that complex matrixes are sometimes misaligned: > { matrix(1i,2,13) } [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [,11] [,12] [,13] [1,] 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i [2,] 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i 0+1i (the values in the last four columns

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