similar to: Failure to turn a div by power of 2 into a single shift

I'd missed the fact that j wasn't just being decremented. This isn't as easy as I said. Philip On 03/03/2016 02:36 PM, Philip Reames via llvm-dev wrote: > SCEV should be able to easily prove that j is positive here. I'm not > sure where the right place to use that information would be in this > case. Sanjoy, can you comment? > > Philip > > On 03/03/2016

Thank you, Adam. It passes all the benchmarks I have. Haicheng From: anemet at apple.com [mailto:anemet at apple.com] Sent: Wednesday, March 09, 2016 7:17 PM To: Haicheng Wu; Eric Christopher; Benjamin Kramer Cc: llvm-dev Subject: Re: Regression in SPEC2006/gcc caused by LoopLoadElimination I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys please give it a

> On Mar 7, 2016, at 9:43 AM, Adam Nemet <anemet at apple.com> wrote: > > Hi Haicheng, > > Sorry about the breakage. I reverted it in r262839. > > I will try to reproduce it locally. Please don’t blow away your directories yet in case I need further help. OK, I managed to reproduce this locally. Should be able to make progress from here without further help from

On Thu, Mar 10, 2016 at 1:17 AM, Adam Nemet <anemet at apple.com> wrote: > I’ve committed the fix in r263058. Haicheng, Eric/Benjamin, can you guys > please give it a test with your codebase. (You need to enable the pass with > -mllvm -enable-loop-load-elim.) The miscompilation I was seeing is gone now, too. Thanks! > On Mar 7, 2016, at 11:05 PM, Adam Nemet <anemet at

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was

Hi, I am working with SCEVs, I see the unsigned division of SCEVs, it is not immediately clear to me why the signed division of SCEV expressions is not supported by SE? I would appreciate if some could clarify or point me to some links. -- Regards, DTharun -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Arnaud, Thanks for following up with that and sorry for the breakage. Couple of comments: MachineLoopInfo *MLI; + RegScavenger *RS; Would it make sense to use a unique_ptr here? That should eliminate the need of having explicit deletes. +; RUN: llc -mtriple=aarch64-linux-gnu -o - %s Add -enable-shrink-wrap=true and a second RUN line with -enable-shrink-wrap=false. Then add check lines

This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact. Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like

Hi Adam, I find LoopLoadElimination (r262250) causes SPEC2006/gcc generate wrong result (166.s) in AArch64 when running with *ref* data set. The error happens when I use either "-Ofast -flto -fuse-ld=gold" or "-O3 -fno-strict-aliasing". Please let me know if you need more information. Best, Haicheng -------------- next part -------------- An HTML attachment was

Hi Haicheng, Originally I ran into this on our out-of-tree target but I managed to reproduce the crash on X86 as well now: build-all/bin/opt -S -sroa -loop-rotate -loop-deletion -licm -loop-idiom ../llvm/bugpoint-reduced-simplified.i8+.ll gives: While deleting: void % An asserting value handle still pointed to this value! UNREACHABLE executed at ../lib/IR/Value.cpp:696! 0 opt

Hi Sanjay, I observed some extra register spills when applying the reassociation pass on spec2006 benchmarks and I would like to listen to your advice. For example, function get_new_point_on_quad() of tria_boundary.cc in spec2006/dealII has a sequences of code like this . X=a+b . Y=X+c . Z=Y+d . There are many other instructions between these float adds. The reassociation

Hi Quentin, After shrink-wrapping was enabled as default on AArch64, llc has a seg fault when compiling the attached .ll file on AArch64. My command is llc -mcpu=cortex-a57 bug.ll Best, Haicheng -------------- next part -------------- A non-text attachment was scrubbed... Name: bug.ll Type: application/octet-stream Size: 8983 bytes Desc: not available URL:

Hi, Yes SCEV is pretty limited on this aspect. This kind of code can trigger LLVM to explode in time/memory: https://llvm.org/bugs/show_bug.cgi?id=18606 <https://llvm.org/bugs/show_bug.cgi?id=18606> See also this llvm-dev thread: SCEV implementation and limitations, do we need "pow"? : http://lists.llvm.org/pipermail/llvm-dev/2014-February/070062.html CC: Sanjoy who may have an

gcc -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I../../../tools/include -I. -c -o hvmloader.o hvmloader.c cc1: warnings being treated as errors

Hi Andy, Andrew Trick wrote: >> On Sep 23, 2016, at 7:50 AM, Christof Douma <Christof.Douma at arm.com <mailto:Christof.Douma at arm.com>> wrote: >> >> I can’t help to ask. Why not define a wrapping nsw instruction as UB, instead of “delayed UB” aka poison? I believe we >> have the notion of poison solely to ease the movement of instructions. In my example

Hi everyone, The code layout that TailMerging (inside BranchFolding) works on is not the final layout optimized based on the branch probability. Generally, after BlockPlacement, many new merging opportunities emerge. I did an experiment of adding additional BranchFolding and BlockPlacement after the existing BlockPlacement (i.e., -block-placement -branch-folder -block-placement) targeting

On 32e, we create one guest, then hotplug attach one NIC to guest, guest can not get IP address via dhcp, guest qemu log shows "libpci read error. No emulation ". Here is the bug entry: One 32e, hotplug attaching VT-d NIC to guest failed. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1316. -- haicheng _______________________________________________ Xen-devel mailing list

All, We met several system failures on different hardware platforms, which are all caused by VT-d fault. err 1: disk is corrupted by VT-d fault on SATA. err 2: Dom0 kernel panics at booting, which is caused VT-d fault on UHCI. err 3, Dom0 complains disk errors while creating HVM guests. The culprit would be changeset 19054 "x86_64: Remove statically-partitioned Xen heap.". Detailed

Hi all, This is our nightly testing report for c/s 17917; no new issue today, and bug #1286 got fixed. Fixed issue: ============================================== 1. guest cannot be created with two disks appended. http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1286 Old issues: ============================================== 1. dom0 hangs with io errors printed while booting hvm

Hi all, This is today''s nightly testing report; no new issue found, bug #1259 got fixed. Some vt-d cases failed in first round testing, but can get pass in retesting. Fixed issue: ============================================== 1. booting windows guest causes Xen HV crash http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1259 Old issues: