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
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 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
On Monday 02 November 2009 13:55, Tanya Lattner wrote:> You 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 exist exactly for these kinds of disruptive changes. We used one for the use-diet so there's precedent. -Dave