similar to: [LLVMdev] Adding legal integer sizes to TargetData

On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: > Now that 2.5 is about to branch, I'd like to bring up one of Scott's > favorite topics: certain optimizers widen or narrow arithmetic, > without regard for whether the type is legal for the target. In his > specific case, instcombine is turning an i32 multiply into an i64 > multiply in order to eliminate a cast. This

On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote: > > On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: > >> Now that 2.5 is about to branch, I'd like to bring up one of Scott's >> favorite topics: certain optimizers widen or narrow arithmetic, >> without regard for whether the type is legal for the target. In his >> specific case, instcombine is

On Feb 2, 2009, at 1:29 PMPST, Chris Lattner wrote: > > On Feb 2, 2009, at 1:26 PM, Dale Johannesen wrote: > >> >> On Feb 1, 2009, at 11:06 PMPST, Chris Lattner wrote: >> >>> Now that 2.5 is about to branch, I'd like to bring up one of Scott's >>> favorite topics: certain optimizers widen or narrow arithmetic, >>> without regard for

> Now that 2.5 is about to branch, I'd like to bring up one of Scott's > favorite topics: certain optimizers widen or narrow arithmetic, > without regard for whether the type is legal for the target. In his > specific case, instcombine is turning an i32 multiply into an i64 > multiply in order to eliminate a cast. This does simplify/reduce the > number of IR operations,

On Thu, Mar 9, 2017 at 10:54 AM, Hal Finkel <hfinkel at anl.gov> wrote: > On 03/09/2017 12:14 PM, Wei Mi via llvm-dev wrote: >> >> In >> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120827/063200.html, >> consecutive bitfields are wrapped as a group and represented as a >> large integer and emits loads stores and bit operations appropriate

On 28 Sep 2016, at 16:50, Philip Reames via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > At this point, my general view is that widening transformations of any kind should be done very late. Ideally, this is something the backend would do, but doing it as a CGP like fixup pass over the IR is also reasonable. I’m really glad to see that this is gone in GVN - it will reduce our

In http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20120827/063200.html, consecutive bitfields are wrapped as a group and represented as a large integer and emits loads stores and bit operations appropriate for extracting bits from within it. It fixes the problem of violating C++11 memory model that original widen load/store of bitfield was facing. It also brings more coalescing

Chen, see http://llvm.org/docs/GettingStarted.html#pf_12 ...Takumi ps. Excuse me, PE+ (aka pep) means "Executable file format for WIndows x64". 2011/5/16 陈晓宇 <xychen0921 at gmail.com>: > The stack trace: > > Starting program: > C:\MinGW\msys\1.0\home\xchen\llvm-obj\lib\Target\CellSPU/../.. > /../Debug/bin/tblgen.exe -I

Ok, thanks. Are there any plans to reintroduce it on the IR level? I'm not confident this is strictly necessary, but in some cases not having load widening ends up really bad. Like in the case where vectorizer tries to do something about it: https://godbolt.org/z/60RuEw https://bugs.llvm.org/show_bug.cgi?id=42708 At the current state I'm forced to use memset() to express uint64 load from

On 03/09/2017 12:28 PM, Krzysztof Parzyszek via llvm-dev wrote: > We could add intrinsics to extract/insert a bitfield, which would > simplify a lot of that bitwise logic. But then you need to teach a bunch of places about how to simply them, fold using bitwise logic and other things that reduce demanded bits into them, etc. This seems like a difficult tradeoff. -Hal > >

I was building llvm2.9 using MinGW64 on windows, msys was 32 bit so I specified --host option for a cross compiling. Following are my configure options: ../llvm2.9/configure --prefix=/home/AutoESL/llvm-obj --host=x86_64-w64-mingw32 --disable-multilib The error: make[1]: Entering directory `/home/AutoESL/llvm-obj/lib/VMCore' make[1]: ***

Hi, Can I ask what is the status of load widening. It seems there is no load widening on IR at all. // Paweł On Wed, Oct 5, 2016 at 1:49 PM Artur Pilipenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Philip and I talked about this is person. Given the fact that load > widening in presence of atomics is irreversible transformation we agreed > that we don't want to do

One of the arguments for doing this earlier is inline cost perception of the original pattern. Reading i32/i64 by bytes look much more expensive than it is and can prevent inlining of interesting function. Inhibiting other optimizations concern can be addressed by careful selection of the pattern we’d like to match. I limit the transformation to the case when all the individual have no uses other

I just ran across something interesting: DAGCombine inserts a 64-bit constant as the result of converting a (bitconvert (fabs val)) to a (and (bitconvert val), i64const). The problem: i64 constants have to be legalized for the CellSPU platform. DAGCombine is doing the right thing but it's not doing the right thing for CellSPU and it's damed difficult to work around this

If we do load combining at the IR level, one thing we'll need to give some thought to is atomicity.  Combining two atomic loads into a wider (legal) atomic load is not a reversible transformation given our current specification. I've been thinking about a concept I've been tentatively calling "element wise atomicity" which would make this a reversible transform by

----- Original Message ----- > From: "Jingyue Wu" <jingyue at google.com> > To: "Daniel Berlin" <dberlin at dberlin.org>, "Mark Heffernan" <meheff at google.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, March 13, 2015 1:31:59 PM >

> On 29 Sep 2016, at 03:23, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Hi Artur, > > Artur Pilipenko via llvm-dev wrote: > > One of the arguments for doing this earlier is inline cost > > perception of the original pattern. Reading i32/i64 by bytes look much > > more expensive than it is and can prevent inlining of interesting > >

On 01/14/2015 04:16 PM, Ahmed Bougacha wrote: > On Thu, Jan 15, 2015 at 12:42 AM, Philip Reames > <listmail at philipreames.com> wrote: >> At a very high level, why do we need these intrinsics? > In short, to catch sequences you can't catch in the SelectionDAG. > >> What is the use case? What are typical values for N? > Typically, you get this from (a little

Hi, I want to improve the way CGP sinks the incoming values of a PHI node towards memory accesses. Improving it means a lot to some of our key benchmarks, and I believe can benefit many general cases as well. CGP's OptimizeMemoryInst function handles PHI nodes by running AddressingModeMatcher on all incoming values to see whether they reach consensus on the addressing mode. It does a

Apologies if this is in the archive - did look but couldn't find it. Does anyone have any experience of migrating from CommunigatePro to Dovecot? We currently run CGP 5.3.4, supporting a small system (20 or so users, one domain). We've been using it for years, and have a mixed bag of MailDir and mbox folders accessed via IMAP clients. Some users have large mail accounts (15GB total).