similar to: [LLVMdev] IndVarSimplify too aggressive ?

On Sun, Mar 13, 2011 at 5:01 PM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64,

Thanks Eli, After digging thru mail archives & bugzilla, it seems fixing properly this issue would require a major change in the selectionDAG code --- to have it operate on a per function basis instead of per basic-block. This however, does not seem to be the only issue. The following C code does not produce an efficicient assembly sequence either. extern void f(unsigned long long v); void

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

On Mar 13, 2011, at 2:01 PM, Arnaud Allard de Grandmaison wrote: > Hi all, > > The IndVarSimplify pass seems to be too aggressive when it enlarge the induction variable type ; this can pessimize the generated code when the new induction variable size is not natively supported by the target. This is probably not an issue for x86_64, which supports natively all types, but it is a real one

Hi, I noticed a significant performance regression (up to 40%) on some internal CUDA benchmarks (a reduced example presented below). The root cause of this regression seems that IndVarSimpilfy widens induction variables assuming arithmetics on wider integer types are as cheap as those on narrower ones. However, this assumption is wrong at least for the NVPTX64 target. Although the NVPTX64 target

Interesting, thanks for digging this up! > As a consequence, any loop structure that is recognized > by SCEV will (/should) not profit from rewriting. As discussed in https://reviews.llvm.org/D68577#1742745 and PR40816 showed, there is still merit and profit in further simplifying loop induction variables, or at-least the primary one; somewhat independent of continuing to rely on SCEV for

I also considered this approach, but did not want to dive in the constraint handling for now. The PBQP path seemed easier at first sight --- and was easy to setup. And I always wanted to give a try to the pbqp :) I will add the hook to the pbqp and propose a patch if this looks clean enough. Thanks, -- Arnaud de Grandmaison -----Original Message----- From: Jakob Stoklund Olesen

While migrating my codebase from llvm-2.6 to llvm-2.7, I found a different behaviour in the register allocation. I have been able to reproduce it using the msp430 backend, with the 2.7 release as well as the svn head. For the msp430, the first four parameters of a function are passed thru registers. What I observe is that if those parameters are not used inside the function, those registers can

On 04/14/2014 02:31 PM, Arnaud Allard de Grandmaison wrote: > Hi All, > > As kindly pointed by Sebastian, please forget my point about the release > script. I read the mail from Tom 2 days ago, and forgot that the script was > available in the tag / branch when I acted today :( > > I uploaded clang+llvm-3.4.1-rc1-x86_64-unknown-ubuntu12.04.tar.xz to > ftp.llvm.org. >

A follow-up question: Is there a way to make different passes accept one command line option that will affect all of them? For example, I'd like to have a -optStrength parameter, that can be given to all of my passes simultaneously. Thanks a lot, Guy Arnaud Allard de Grandmaison wrote: > > Hi Harel, > > Several existing passes can take command line arguments. Have a look at

On Fri, Sep 11, 2015 at 10:06 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Also, if these redundant expressions involve induction variables, then that's something that the IndVarSimplify is already supposed to do, and if it is missing cases, then we should improve that pass (and, thus, folding what you've done into IndVarSimplify might be the right way to go). Hal, thanks for the

Hi All, My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. Instruction 'MPQD' takes 3 register operands inputs, with the constraint that operands 0 and 2 must be consecutive registers. Operand 1 has no particular constraint. It has no output register.

Hello, Quick question to see if I haven't missed anything: I would like convert counting down loops, i.e. loops with a constant -1 step value, to counting up loops, because the vectoriser is able to better deal with these loops (see e.g. D76838 that I was discussing today with Ayal). It looks like LoopSimplifyCFG and IndVarSimplify don't do this. So was just curious if I haven't

Hi Arnaud, That sounds great. I look forward to seeing a patch. You may also look forward to big performance improvements in the PBQP allocator: I'm working on updates which will improve compile speeds and massively reduce memory use. Regards, Lang. On Tue, Jun 7, 2011 at 7:02 PM, Arnaud Allard de Grandmaison < Arnaud.AllardDeGrandMaison at dibcom.com> wrote: > > I also

On Tue, Oct 19, 2010 at 12:19 AM, Arnaud Allard de Grandmaison <Arnaud.AllardDeGrandMaison at dibcom.com> wrote: >> But if the usage was in a loop it would be better (at the cost of >> register pressure) to materialise 5 into a register outside of the >> loop and use the register repeatedly in the loop. > > Bouncing on this subject: you can not know before isel is

On Jun 6, 2011, at 7:07 AM, Arnaud Allard de Grandmaison wrote: > Hi All, > > My target has some instructions requiring register pairs. I decided to give a try to the PBQP allocator : it is working fine in 99% of the cases, but I am stumbling on the following issue. > > Instruction ‘MPQD’ takes 3 register operands inputs, with the constraint that operands 0 and 2 must be

Hi Steve it seems the general consensus is that the patch feels like a work-around for a problem with LSR (and possibly other loop transformations) that introduces redundant instructions. It is probably best to file a bug and a few of your test cases. Thanks Gerolf > On Sep 10, 2015, at 4:37 PM, Steve King via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 10, 2015

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced

You could make the cl:opt object visible outside one of your passes, and use it in your other passes : in other words, it is a global variable shared between several files. Best regards, -- Arnaud de Grandmaison -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of guyadini Sent: Thursday, January 27, 2011 12:38 PM To: llvmdev at

On Nov 16, 2010, at 1:19 AM, Arnaud Allard de Grandmaison wrote: > Hi Dan, > > The tutorial in r119335 does not build : the basicAA pass creation needs to be declared. This is addressed with the 'missing-include' patch, which updates both source code & documentation. Applied, thanks. > The second point is that beside basicAA, to get the optimizations as shown in the