similar to: [LLVMdev] Unrolling an arithmetic expression inside a loop

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic.

Which cases does this pass handle which aren't otherwise optimized out by passes like GlobalValueNumbering or DeadCodeElimination? Thanks, Jake VanAdrighem On Thu, Sep 10, 2015 at 2:35 PM, Steve King <steve at metrokings.com> wrote: > Hello LLVM, > It seems this thread has gone cold. Is there some low risk way for > the community to take the new pass for a test drive? >

Hi Steve, Do you primarily find this to help for nested loops? If so, that could be because LSR explicitly bails out of processing them: // Skip nested loops until we can model them better with formulae. if (!L->empty()) { DEBUG(dbgs() << "LSR skipping outer loop " << *L << "n"); return; } I don't know how much time you're

Hi, The compilation of the following code void f(int *a, int b[], int n) { int i; for(i=0; i< n; ++i) a[i] = b[i]; } gives the IR: define void @f(i32* nocapture %a, i32* nocapture %b, i32 %n) nounwind { %1 = icmp sgt i32 %n, 0 br i1 %1, label %.lr.ph, label %._crit_edge .lr.ph: ; preds = %0 %tmp = zext i32 %n to i64 br label %2 ;

On Mon, Aug 31, 2015 at 5:52 PM, Jake VanAdrighem <jvanadrighem at gmail.com> wrote: > Do you have some specific performance measurements? Averaging 4 runs of 10000 iterations each of Coremark on my X86_64 desktop showed: -O2 performance: +2.9% faster with the L.E.V. pass -Os size: 1.5% smaller with the L.E.V. pass In the case of Coremark, the benefit comes mainly from the matrix

On 12 June 2010 00:51, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: >> Hi Eli, >> >> On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote:

I was able to get the loop to increment from -999 to 0 using IR directly. That got rid of the cmpq. The carry i was after was able to be obtained using the intrinsic @llvm.uadd.with.overflow.i64, however there is no way to add with carry and have it realise that the resulting *carry out* cannot exceed 1. It actually writes the carry to a byte, and then uses logical operations on it, which slows

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The

Hello, I noticed that feeding 'clang -O3' with functions like: int sum1(int x) { int ret = 0; for(int i = 0; i < x; i++) ret += i; return ret; } int sum2(int x) { int ret = 0; for(int i = 0; i < x; i++) ret += i*i; return ret; } ... int sum20(int x) { int ret = 0; for(int i = 0; i < x; i++) ret +=

On Wed, Sep 23, 2015 at 12:00 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> Should we try the patch in it's current location, namely after LSR? > > Sure; post the patch as you have it so we can look at what's going on. > http://reviews.llvm.org/D12494 One particular point: The algorithm checks that SCEV's are equal when their raw pointers are equal. Is

Hello, I've come across another example: I'm compiling with clang -S -emit-llvm -std=gnu99 -O3 clang version 2.9 (trunk 118238) Target: x86_64-unknown-linux-gnu Thread model: posix I take the code: int loops(int x) { int ret = 0; for(int i = 0; i < x; i++) { for(int j = 0; j < x; j++) { ret += 1; } } return ret; } and the

Hi! When I'm trying to run wine (I've tried many compilations), I got something like that: wineserver: /root/.wine/config is not a valid registry file Why I'm not using /etc/wine.conf, /usr/etc/wine.conf or /usr/local/etc/wine.conf? Because wineserver wants only $HOME/.wine/config... When I delete this file wineserver 'says' that I don't have configuration file (even

Yeah I had a think about it, and I think intrinsics are the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to

On Oct 21, 2011, at 12:15 AM, James Molloy wrote: > Hi Andy, > > Could you describe how this would be done? In the current ARM itineraries > (say C-A9 for example), the superscalar issue stage is modelled as taking 1 > cycle. If it were to take 2 cycles instead, as far as I can tell the hazard > analyser would stall because both FU's would be acquired. > > I would

Hiya, I want to know what's the type of the operand (value) along with the store instruction. For example, the following instruction store the content in an integer type pointer scevgep99.1 to the address another integer pointer points to. *"store i8* %scevgep99.1, i8** %scevgep92.1, align 4"* It seems there is no APIs in StoreInst can do this. Is there any way to figure the type

Zheng Wang wrote: > Hiya, > > I want to know what's the type of the operand (value) along with the > store instruction. For example, the following instruction store the > content in an integer type pointer scevgep99.1 to the address another > integer pointer points to. > > *"store i8* %scevgep99.1, i8** %scevgep92.1, align 4"* > > It seems there is no

On Wed, Jun 16, 2010 at 1:39 PM, Pierre C <lists at peufeu.com> wrote: > > I'm hitting a strange pointer aliasing "bug". Here is a test case : > > /* SOURCE CODE */ > > #define little_list_size 8 > > class LittleList1 { > public: >        int     _length; >        double  _data[ little_list_size ]; > >        LittleList1( int length ) >

I'm hitting a strange pointer aliasing "bug". Here is a test case : /* SOURCE CODE */ #define little_list_size 8 class LittleList1 { public: int _length; double _data[ little_list_size ]; LittleList1( int length ) { _length = length; for( int i=0; i<length; i++ ) _data[i] = 0; } }; class LittleList2 { public: int _length; double _data[ little_list_size ];