search for: natebegeman

On Feb 23, 2009, at 2:49 PM, Scott Michel wrote: > On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com> > wrote: > > On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > > In my opinion, the proper direction for shuffles is: > > 1. Back out your patch. > 2. Move the functionality of "is splat" etc to method somewhere, e.g. > on SDNode. > 3. Intro...

On Mon, Feb 23, 2009 at 2:19 PM, Nate Begeman <natebegeman at me.com> wrote: > > On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > > In my opinion, the proper direction for shuffles is: >> >> 1. Back out your patch. >> 2. Move the functionality of "is splat" etc to method somewhere, e.g. >> on SDNode. &g...

On Feb 23, 2009, at 1:46 PM, Chris Lattner wrote: > In my opinion, the proper direction for shuffles is: > > 1. Back out your patch. > 2. Move the functionality of "is splat" etc to method somewhere, e.g. > on SDNode. > 3. Introduce a new ShuffleVectorSDNode that only has two SDValue > operands (the two input vectors), but that also contains an array of > ints in

On Feb 23, 2009, at 6:13 PM, Scott Michel wrote: > On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> > wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, > and appropriate helper functions, node profile, and DAGCombiner > support. > > Fine. For vector shuffles. But again, what about vector constants, > e.g., v4i32 <0,...

On Feb 23, 2009, at 10:30 PM, Scott Michel wrote: > On Mon, Feb 23, 2009 at 8:26 PM, Chris Lattner <clattner at apple.com> > wrote: > > On Feb 23, 2009, at 6:13 PM, Scott Michel wrote: > >> On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> >> wrote: >> >> It's basically as Chris said; there will be a ShuffleVectorSDNode, >> and appropriate helper functions, node profile, and DAGCombiner >> support. >> >> Fine. For vector shuffles. But again, what about vector constant...

On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> wrote: > > It's basically as Chris said; there will be a ShuffleVectorSDNode, and > appropriate helper functions, node profile, and DAGCombiner support. > Fine. For vector shuffles. But again, what about vector constants, e.g., v4i32 <0, 1, 2, 3, 4>? BuildVect...

On Mon, Feb 23, 2009 at 8:26 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 23, 2009, at 6:13 PM, Scott Michel wrote: > > On Mon, Feb 23, 2009 at 4:03 PM, Nate Begeman <natebegeman at me.com> wrote: > >> >> It's basically as Chris said; there will be a ShuffleVectorSDNode, and >> appropriate helper functions, node profile, and DAGCombiner support. >> > > Fine. For vector shuffles. But again, what about vector constants, e.g., > v4i3...

I doubt anyone is using it, as it is not complete. On Jun 1, 2009, at 9:12 AM, Aaron Gray wrote: > Is anyone using the MachO Writer ? > > If so do you have any test cases as I am moving it over to use the > prototype direct object emission code and I need test cases to > verify it working correctly. > > Many thanks in advance, > > Aaron > >

On Jun 1, 2009, at 12:18 PM, Aaron Gray wrote: > Nate, > > Right, okay. I was also planning on looking at what the assembly > output generates and "emulating" its output. Sure. I was using the source for 'as' and 'ld' as my guide when I was working on it. > > So I should be able to use the 'test/CodeGen/PowerPC' tests once I > have

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

Hi Everyone! We are pleased to announce the impending checkin to CVS of the PowerPC / MachO backend for LLVM. Many thanks go out to all the LLVM developers for their help in making this happen. Misha Brukman and Chris Lattner will be handling the CVS integration in the near future. The PowerPC BE current compiles most of the testsuite correctly. There are known issues in C++, variable

On Jun 24, 2009, at 10:02 AM, Chris Lattner wrote: > > On Jun 24, 2009, at 12:47 AM, Duncan Sands wrote: > >> Hi Nick, >> >>> Now that icmp and fcmp have supported returning vectors of i1 for a >>> while, >> >> the code generators don't know how to codegen vectors of i1, so does >> this actually work? > > No, but there are no

On Mar 23, 2009, at 12:57 PM, David A. Greene wrote: > I'm looking at the instruction formats and I can't grok the > comments. For > example: > > // SSSE3 Instruction Templates: > // > // SS38I - SSSE3 instructions with T8 prefix. > // SS3AI - SSSE3 instructions with TA prefix. > // > > Where are these prefix names coming from? I can't find any

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

Hi Christopher, I can send you what I have for that so far, that works pretty well. Nate On Jun 6, 2007, at 3:06 PM, Christopher Lamb wrote: > > On Apr 24, 2007, at 12:01 PM, Chris Lattner wrote: > >> Yes, we need those. I think these are the major pieces needed. >> These are >> all relatively small and independent pieces, so we can tackle >> these one at

Are you using isTarget = 1 in your intrinsics file? On Apr 14, 2009, at 6:34 PM, Villmow, Micah wrote: > It seems that Tablegen is generating intrinsic ID’s off by in > DAGISel.inc > > In DAGISel.inc, I have the following pattern: > int64_t CN1 = Tmp0->getZExtValue(); > > // Pattern: (intrinsic_w_chain:f32 103:iPTR, GPRF32:f32:$src0, > GPRF32:f32:$src1,

On Jun 13, 2008, at 12:27 AM, Nicolas Capens wrote: > Hi all, > > When trying to generate a VFCmp instruction when UnsafeFPMath is set > to true I get an assert “Unexpected CondCode” on my x86 system. This > also happens with UnsafeFPMath set to false and using an unordered > compare. Could someone look into this? > > While I’m at it, is there any reason why only the

On Apr 14, 2009, at 9:46 AM, Dan Gohman wrote: > There's at least one other LLVM user which would find these > useful, and probably more, so it may be appropriate to merge > this into the main tree. I'm interested to hear if anyone > else has an opinion here. I'd rather not see them in the main tree, since there's no real explanation of what the benefits would be

On Jul 21, 2008, at 1:21 PM, Stefanus Du Toit wrote: > Hi, > > We would like to extend the vector operations in llvm a bit. We're > hoping to get some feedback on the right way to go, or some starting > points. I had previously had some discussion on this list about a > subset of the changes we have in mind. > > All of these changes are intended to make