similar to: [LLVMdev] X86 LowerVECTOR_SHUFFLE Question

David Greene <dag at cray.com> writes: > In ToT, LowerVECTOR_SHUFFLE for x86 has this code: > > if (X86::isUNPCKLMask(SVOp)) > getTargetShuffleNode(getUNPCKLOpcode(VT) dl, VT, V1, V2, DAG); > > why would this not be: > > if (X86::isUNPCKLMask(SVOp)) > return SVOp; Ok, I discovered that Bruno did this in revisions 112934, 112942 and 113020 but the logs

It is inefficient and error-prone to recognize legal shuffles and then have isel repeat the process. For example, if the DAG combiner changes a shuffle in between legalization and isel, it may stop being legal and break isel. By legalizing to target-specific DAG nodes, we avoid that possibility and also make it much easier to match the shuffles during isel. On Feb 25, 2011, at 6:01 PM, David A.

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> There's certainly been improvement on the TableGen side of things.  I >> really liked the unpck*, shufp, etc. nodes and the ShuffleVectorSDNode. >> That's a huge help.  It's too bad we're getting rid of them.  But >> legalization still looks about the same to me. > > The idea is to use

Bob Wilson <bob.wilson at apple.com> writes: > It is inefficient and error-prone to recognize legal shuffles and then > have isel repeat the process. For example, if the DAG combiner > changes a shuffle in between legalization and isel, it may stop being > legal and break isel. By legalizing to target-specific DAG nodes, we > avoid that possibility and also make it much

> Maybe.  We still have the old operators like unpck and shup, so couldn't > those still trigger?  Shouldn't we remove them if we're using this > TargetNode method? > > Is it very expensive to check masks, in the grand scheme of things? Probably not, in the old scheme the masks could be checked more than once during legalization and also more than once in the tablegen

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> writes: >> It really doesn't seem worth it to me. > > In the way it was done before, every shuffle that we tried to match > had to be checked twice (masks used to be checked during legalization > and during isel by the tblgen patterns), Right. > this is done only once now (during legalization). Maybe. We still

> In the experience I just had, it is quite error-prone to have multiple > tblgen patterns to match these things.  The way things were before, > there was a clean separation between checking/enforcing node legality > and doing the final code selection, with isel being automatic through > tblgen.  That was nice.  The current setup mixes the two and seems to > result in more code

Yep, I'm fixing it (and others) now. Good catch. Evan On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > > On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >> >> >> Since I’m fairly new to LLVM I’m not entirely sure if this is really >> a bug or something I’m not doing correctly, or whether it’s already >> being addressed. The following thread appears to

Hi Evan, The commit http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20060327/033389.html broke CVS. The attached obvious patch fixes it. I don't have write access . So can someone commit this in ? ramana at zirakzigil:~/fsf/llvm/llvm/lib/Target/X86$ cvs diff -au X86ISelLowering.cpp Index: X86ISelLowering.cpp ===================================================================

Hi all, I think I might have found a potential bug when using SSE intrinsic and unaligned memory. Here's the code to reproduce it: #include "llvm/Module.h" #include "llvm/Intrinsics.h" #include "llvm/Instructions.h" #include "llvm/ModuleProvider.h" #include "llvm/ExecutionEngine/JIT.h" #include

On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: > > > Since I’m fairly new to LLVM I’m not entirely sure if this is really > a bug or something I’m not doing correctly, or whether it’s already > being addressed. The following thread appears to talk about > something similar:http://thread.gmane.org/gmane.comp.compilers.llvm.devel/9476/focus=9478 Looking at LLVM's

Fixed. Evan On May 22, 2008, at 5:02 PM, Evan Cheng wrote: > Yep, I'm fixing it (and others) now. Good catch. > > Evan > > On May 22, 2008, at 4:59 PM, Dan Gohman wrote: > >> >> On May 22, 2008, at 4:24 PM, Nicolas Capens wrote: >>> >>> >>> Since I’m fairly new to LLVM I’m not entirely sure if this is really >>> a bug or

I'd like to start moving some of our AVX work into trunk. We've got quite a bit of it implemented already. I wanted to make sure we got something that would work and remain relatively stable. Here's how I'd like to do this. First, I have some more TableGen fixes and enhancements that are prereqs for AVX templates. I'd like to get those in first. Then there are a number of

On Sep 21, 2010, at 10:23 AM, Nicolas Capens wrote: > Hi all, > > Sorry for the late reply. I got sidetracked by other fun projects. ;-) > > I found that the performance regression is caused by revisions 112804, > 112805 and 112806. Those changes were made 2 days prior to the 2.8 > branching, so it may have not been the intention to include them there? > Either way they

On Wed, Sep 8, 2010 at 12:35 AM, Nicolas Capens <nicolas.capens at gmail.com> wrote: > Hi Chris, > > It's not broken, but the performance is crippled. > > I noticed that the code still contains some MMX instructions, but several > operations get expanded (apparently swizzling and such get expanded to a > large number of byte moves). I think some changes related to

Here's the big RFC. A I've gone through and designed patterns for AVX, I quickly realized that the existing SSE pattern specification, while functional, is less than ideal in terms of maintenance. In particular, a number of nearly-identical patterns are specified all over for nearly-identical instructions. For example: let Constraints = "$src1 = $dst" in { multiclass

On Mar 17, 2011, at 9:32 AM, David A. Greene wrote: > Chris Lattner <clattner at apple.com> writes: >>> 1. We have special target-specific operators for certain shuffles in X86, >>> such as X86unpckl. > >> It also eliminates a lot of fragility. Before doing this, X86 >> legalize would have to be very careful to specifically form shuffles >> that

Chris Lattner <clattner at apple.com> writes: >> We would still keep the existing pre-table-driven-isel passes so we'd >> still have a chance to do some cleanup before the main table-driven >> isel. >> >> Obviously a lot of details have to be worked out. > > I'm not seeing how this is useful for shuffles. Since tblgen doesn't > generate

Chris Lattner <clattner at apple.com> writes: >> 1. We have special target-specific operators for certain shuffles in X86, >> such as X86unpckl. > It also eliminates a lot of fragility. Before doing this, X86 > legalize would have to be very careful to specifically form shuffles > that it knew isel would turn into (e.g.) unpck operations. Now > instead of

On Wed, May 20, 2009 at 5:26 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: >> Can you explain why you chose the approach of using a new pass? >> I pictured removing LegalizeDAG's type legalization code would >> mostly consist of finding all the places that use TLI.getTypeAction