similar to: [LLVMdev] Optimization bug - spurious shift in partial word test

Hi Sanjay, You used Alive correctly, of course :) At this moment we cannot give you the best precondition. It’s on the todo list, but it’s not even started yet. It’s a much harder problem to solve. We do have a mode to compute the best set of nsw/nuw/exact attributes in the transformed expression, but it’s not enabled on the web interface yet (InstCombine was missing quite a few cases last

Not sure how off-topic this is, but should we consider/have we considered porting our InstCombines to Alive? The PLDI '15 paper even demos C++ extraction from Alive theorems. I think it'd be a small step from that to extracting tightly optimized VM code, not unlike what Tablegen emits. Everything would be so clean and readable and organized. And edge cases can still be handled manually,

Hi, We found that today's 17.30%/11.37% performance regressions in LNT SingleSource/Benchmarks/Shootout/sieve on LNT-AArch64-A53-O3__clang_DEV__aarch64 and LNT-Thumb2v7-A15-O3__clang_DEV__thumbv7 (http://llvm.org/perf/db_default/v4/nts/daily_report/2017/1/20?filter-machine-regex=aarch64%7Carm%7Cthumb%7Cgreen) are caused by changes [rL292492] in InstCombine: https://reviews.llvm.org/D28406

Hi Sanjay, The benchmark source file: http://www.llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/Benchmarks/Shootout/sieve.c?view=markup Clang options used to produce the initial IR: clang -DNDEBUG -O3 -DNDEBUG -mcpu=cortex-a53 -fomit-frame-pointer -O3 -DNDEBUG -w -Werror=date-time -c sieve.c -S -emit-llvm -mllvm -disable-llvm-optzns --target=aarch64-arm-linux Opt options: opt -O3

Thank you for information. I’ll build clang without the hack and re-run the benchmark tomorrow. -Evgeny From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 22, 2017 8:00 PM To: Evgeny Astigeevich Cc: llvm-dev; nd Subject: Re: [InstCombine] rL292492 affected LoopVectorizer and caused 17.30%/11.37% perf regressions on Cortex-A53/Cortex-A15 LNT machines > Do you mean to

Confirm there is no change in IR if the hack is disabled in the sources. David wrote that these instructions are created by SCEV. Are other targets affected by the changes, e.g. X86? Kind regards, Evgeny Astigeevich Senior Compiler Engineer Compilation Tools ARM From: Sanjay Patel [mailto:spatel at rotateright.com] Sent: Sunday, January 22, 2017 10:45 PM To: Evgeny Astigeevich Cc: llvm-dev; nd

> On Jan 23, 2017, at 3:48 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > All targets are likely affected in some way by the icmp+shl fold introduced with r292492. It's a basic pattern that occurs in lots of code. Did you see any perf wins on your targets with this commit? > > Sadly, it is also likely that many (all?) targets are negatively

> On Jan 24, 2017, at 7:18 AM, Sanjay Patel <spatel at rotateright.com> wrote: > > > > On Mon, Jan 23, 2017 at 10:53 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: > >> On Jan 23, 2017, at 3:48 PM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>

Hi Sanjay, Thank you for your analysis. It’s interesting why the x86 machine is not affected. Maybe the x86 backend is smarter than the AArch64 backend, or it might be micro-architectural differences. I don’t mind to keep the changes on trunk. What I’d like to see is who will/should be involved in solving the issue. What kind of help/support is needed? Should we (ARM Compilation Tools) start

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 Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined.

On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > >

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking

Hi, Just a short email to announce that Alive is now available online: http://rise4fun.com/Alive The site includes a few examples (both correct and buggy). You can also create a "permalink" to send the proof to someone else. The execution time is limited to 30 seconds for now. You may want to constrain the operand's types if the tool times out, for example. The service is

hello, My 2nd issue is about acls which are added by "Domain users". May you help me to solve it again ? Concerning this issue, on my samba share, I set permissions for the share "groups" located on /var/datashared for "domain admins" (rwx) and "domain users" (r-x) /var]# getfacl datashared/ # file: datashared/ # owner: root # group: root user::rwx

With LLVM 3.8 the JIT compiler engine generates an AVX512 instruction although I target an 'avx2' CPU (intel Core I7). I just downloaded the most recent 3.8 and still it happens. It happens with this input module: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" define void @module_cFFEMJ(i64 %lo, i64 %hi, i64 %myId, i1 %ordered, i64 %start, i32* noalias align 32

I noticed this oddity about [ and setMethod. First, I define testFunc, which sorts a data frame by the first column and returns the entries that aren't NAs, and testIt, which runs testFunc repeatedly on a random large data frame, each time saving the return into a dummy placeholder (for demonstration's sake). > require(methods) Loading required package: methods [1] TRUE > testFunc

I noticed this oddity about [ and setMethod. First, I define testFunc, which sorts a data frame by the first column and returns the entries that aren't NAs, and testIt, which runs testFunc repeatedly on a random large data frame, each time saving the return into a dummy placeholder (for demonstration's sake). > require(methods) Loading required package: methods [1] TRUE > testFunc

Hi, I am trying to compile a FORTRAN program to call from R under Windows 7 but I am having problem in the compiling step. To demonstrate this is the program testit.f: ------------------------------------------ subroutine TESTIT(x,n,m) dimension x(n) do 10 i=1,n 10 x(i)=x(i)**m end -------------------------------------------- When I compile it with gfortran I get

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast