search for: x86instss

...should do incremental development on trunk. If you create a > branch, no one is going to look at those changes. Ok. but I want to be very clear what that means. It means for each AVX instruction I rip out ALL of the existing SSE support for it. So when ADD gets implemented, ADD goes away from X86InstSSE.td. As things progress, we're almost certainly going to have to refactor or otherwise change things we've done in the past. That means extensive .td changes and some very large commits. If everyone's ok with this kind of churn on trunk, that's what I'll do. But SVN branches...

...n fixes and enhancements that are prereqs for AVX templates. I'd like to get those in first. Then there are a number of foundational templates that shouldn't affect anything else. I'll put those in next. Then the fun begins. The first step is to move some some of the templates from X86InstSSE.td out into a new file (I've called it X86InstrFragmentsSIMD.td in our tree). These are things like memopv4f32, alignedload, etc. These are foundational things we need for both AVX and SSE. The goal is to eventually replace X86InstrSSE.td entirely with a set of patterns that covers all SIMD...

...gt;> pattern slightly so it won't match anything and then my pattern gets >> used (so I know my pattern is valid). >> >> Also, I really wanted to express this pattern as transforming from one >> DAG to another, not down to machine instructions. I saw this in >> x86InstSSE.td: >> >> // FIXME: may not be able to eliminate this movss with coalescing the >> src and >> // dest register classes are different. We really want to write this >> pattern >> // like this: >> // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR...

...rst and it isn't selected. I change the other pattern slightly so it won't match anything and then my pattern gets used (so I know my pattern is valid). Also, I really wanted to express this pattern as transforming from one DAG to another, not down to machine instructions. I saw this in x86InstSSE.td: // FIXME: may not be able to eliminate this movss with coalescing the src and // dest register classes are different. We really want to write this pattern // like this: // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), // (f32 FR32:$src)>; (this is actually a...

On Nov 2, 2009, at 11:48 AM, David Greene wrote: > Hey everyone, > > I'm at the point with our local AVX tree that I'm ready to move some > stuff upstream. We've got most of the basic stuff implemented. The > more esoteric stuff still has to be done. > > Because the more esoteric stuff might require some extensive changes > to > the existing AVX

...ent on trunk. If you create a >> branch, no one is going to look at those changes. > > Ok. but I want to be very clear what that means. It means for each > AVX > instruction I rip out ALL of the existing SSE support for it. So when > ADD gets implemented, ADD goes away from X86InstSSE.td. > > As things progress, we're almost certainly going to have to refactor > or > otherwise change things we've done in the past. That means extensive > .td changes and some very large commits. Yep, that's the right thing to do. Just make sure that each patch is...

On Sep 23, 2008, at 11:26 AM, David Greene wrote: > Are there any examples of using tablegen to generate multiple machine > instructions from a single pattern? Or do these cases always have > to be > manually expanded? PPC has a bunch of examples, for example: // Arbitrary immediate support. Implement in terms of LIS/ORI. def : Pat<(i32 imm:$imm), (ORI (LIS (HI16

Are there any examples of using tablegen to generate multiple machine instructions from a single pattern? Or do these cases always have to be manually expanded? -Dave

Hey everyone, I'm at the point with our local AVX tree that I'm ready to move some stuff upstream. We've got most of the basic stuff implemented. The more esoteric stuff still has to be done. Because the more esoteric stuff might require some extensive changes to the existing AVX infrastructure, I suspect there might be quite a bit of church until we get things stabilized. Due to

...hange the > other > pattern slightly so it won't match anything and then my pattern gets > used (so I know my pattern is valid). > > Also, I really wanted to express this pattern as transforming from one > DAG to another, not down to machine instructions. I saw this in > x86InstSSE.td: > > // FIXME: may not be able to eliminate this movss with coalescing the > src and > // dest register classes are different. We really want to write this > pattern > // like this: > // def : Pat<(f32 (vector_extract (v4f32 VR128:$src), (iPTR 0))), > // (...