Moving AVX Upstream

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 that, I'm proposing we create an "avx" branch so I can push changes
upstream, get feedback, etc. without disturbing everyone else too much.
I would make changes incrementally, substituting an AVX definition of
existing SSE instructions and removing them from X86InstrSSE.td at the
same time. That way we'll know when I've broken something.

Then when it's ready we can move the whole bunch over at once.

Does this sound reasonable, or do people prefer I merge to trunk? Merging
to trunk will expose changes to more testing but could also cause a lot of
pain for people. These are really EXTENSIVE changes to the x86 .td files
and there could be more extensive changes in the future as I write some of
the more complicated patterns.

If a branch is preferable, can we get that created? Will commits to the
branch go to the -commits list? It would be even better if -commits
subject lines could be tagged with "[avx]" or something. What was the
precedure for the use-diet branch?

                              -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 that, I'm proposing we create an "avx" branch so I can push changes
upstream, get feedback, etc. without disturbing everyone else too much.
I would make changes incrementally, substituting an AVX definition of
existing SSE instructions and removing them from X86InstrSSE.td at the
same time. That way we'll know when I've broken something.

Then when it's ready we can move the whole bunch over at once.

Does this sound reasonable, or do people prefer I merge to trunk? Merging
to trunk will expose changes to more testing but could also cause a lot of
pain for people. These are really EXTENSIVE changes to the x86 .td files
and there could be more extensive changes in the future as I write some of
the more complicated patterns.

You should do incremental development on trunk. If you create a branch, no one is going to look at those changes.

If a branch is preferable, can we get that created? Will commits to the
branch go to the -commits list? It would be even better if -commits
subject lines could be tagged with "[avx]" or something. What was the
precedure for the use-diet branch?

Nope, it won't go to llvm-commits, it goes to a separate branch mailing list.

-Tanya

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 exist exactly for these kinds of disruptive changes.
We used one for the use-diet so there's precedent.

                           -Dave

Yep, that's the right thing to do. Just make sure that each patch is monotonic progress over the last one (doesn't introduce any known failures or bugs). Thanks David,

-Chris

Ok. Cray is moving to St. Paul this week (yay!) so I'm not going to
send anything until we're settled in next week. That way I'll see the
feedback semi-immediately.

                            -Dave