similar to: [LLVMdev] AVX Shuffles & PatLeaf Help Needed

On Dec 17, 2009, at 3:10 PM, David Greene wrote: > I'm working on debugging AVX shuffles and I ran into an interesting > problem. > > The current isSHUFPMask predicate in X86ISelLowering needs to be > generalized to operate on 128-bit or 256-bit masks. There are > probably lots of other things to change too (LowerVECTOR_SHUFFLE_4wide, > etc.) but I'll worry about

On Thursday 17 December 2009 17:16, Nate Begeman wrote: > David, this is probably the wrong approach, based on the accreted awfulness > of the X86 shuffle lowering code, Ha! I have no issue believing this statement. :) > The correct approach is probably a rewrite based around what > AltiVec does: Canonicalize to byte ops, and write all the patterns once > rather than having to

Hello, David > Can you expand on this with an example?  There seems to be an awful lot of > shuffle patterns and predicates in PPCInstrAltivec.td.  What do you mean by, > "Canonicalize to byte ops?"  Can you walk me through how that works with > Altivec? The basic idea is quite simple - lower everything to vNi8 and write all the patterns using only these types. -- With

On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote: > Hello, David > > > Can you expand on this with an example?  There seems to be an awful lot > > of shuffle patterns and predicates in PPCInstrAltivec.td.  What do you > > mean by, "Canonicalize to byte ops?"  Can you walk me through how that > > works with Altivec? > > The basic idea is

On Dec 17, 2009, at 4:12 PM, David Greene wrote: > On Thursday 17 December 2009 18:04, Anton Korobeynikov wrote: >> Hello, David >> >>> Can you expand on this with an example? There seems to be an awful lot >>> of shuffle patterns and predicates in PPCInstrAltivec.td. What do you >>> mean by, "Canonicalize to byte ops?" Can you walk me

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

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 ===================================================================

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: >> 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 Mar 27, 2011, at 1:16 PM, David A. Greene wrote: > 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 have a few questions about the new vector shuffle matching code in the x86 .td files. It's a big improvement over the old system and provides the context that code generation for AVX needs. This is great! I'm asking because I'm having some trouble converting some AVX patterns over to the new system. I'm getting this error from tblgen: VyPERM2F128PDirrmi: (set:isVoid

These two patches implement the first (and hardest) part of the fix for CVE-2010-3851. This adds a way to specify the format when adding a drive, avoiding qemu's auto-detection. In order to avoid an explosion of different add_drive_* functions (we have 4 already), we have implemented a way to specify optional arguments to functions, so all we need is a single new 'add_drive_opts'

If I try the following: class foo { define bar ($text) { file {"/tmp/foo.txt": content => $text, } } bar { "hello": text => ''Hello World'', } } class foo2 inherits foo { Foo::bar["default"] { text => ''Hello World Again'', } } I get: "Syntax error at '':''; expected

On Friday 01 May 2009 13:46, Chris Lattner wrote: > Right, a lot of these problems can be solved by some nice refactoring > stuff. I'm also hoping that some of the complexity in defining > shuffle matching code can be helped by making the definition of the > shuffle patterns more declarative within the td file. It would be > really nice to say that "this shuffle does a

Simon Pilgrim <llvm-dev at redking.me.uk> writes: > Changing a test's IR to avoid an issue in a patch is very problematic, > but if any test's codegen changes because of a patch then it just > needs to be reviewed, preferably by someone who has touched that test > in the past. But wouldn't it be even better if that output didn't need to be changed at all and

[NOTE: Removed Phab and reviewers] > ================ > Comment at: test/CodeGen/X86/2012-01-12-extract-sv.ll:12 > +; CHECK-NEXT: vblendps {{.*#+}} xmm1 = xmm1[0],xmm2[1,2,3] > +; CHECK-NEXT: vpermilps {{.*#+}} xmm0 = xmm0[0,0,0,0] > ; CHECK-NEXT: vinsertf128 $1, %xmm0, %ymm0, %ymm0 > ---------------- > greened wrote: >> Can we make this test less brittle by

On Tuesday 05 May 2009 01:02, Evan Cheng wrote: > I think it makes sense for isel to use HW cost (instruction latency, > code size) as a late tie breaker. In that case, shouldn't cost be part > of instruction itinerary? What latency? Each implementation has its own quirks and LLVM must be flexible enough to handle them. So cost needs to be a function of the CPU type as well as the

On May 1, 2009, at 3:50 PM, Chris Lattner wrote: > > The goal is to replace the pattern fragment and the C++ code for > X86::isMOVDDUPMask with something like: > > def movddup : PatFrag<(ops node:$lhs, node:$rhs), > (vector_shuffle node:$lhs, node:$rhs, > 0, 1, 0, 1, Cost<42>) > > Alternatively, the

On Apr 30, 2009, at 3:59 PM, David Greene wrote: > Here's the big RFC. > > > Of course we would not transition away from X86InstrSSE.td until > X86InstrSIMD.td is proven to cover all current uses of SSE correctly. > > The pros of the scheme: > > * Unify all "important" x86 SIMD instructions into one framework and > provide > consistency While

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