llvm dev - Jan 2015 - [LLVMdev] Heads up! Planning to remove old vector shuffle lowering this week...

On Sun, Jan 4, 2015 at 3:20 PM, Simon Pilgrim <llvm-dev at redking.me.uk>
wrote:
> On 24 Nov 2014, at 17:53, Chandler Carruth <chandlerc at gmail.com>
wrote:
>
> > I'll be skimming the PRs to see if there are any really critical
> regressions, but so far it looks pretty good.
> >
> > If you are actively disabling the new vector shuffling and have some
PR
> that blocks you, please reply here. Later this week, the flag will go away
> unless I hear strenuous objections. There is a really staggering amount of
> cleanup and tidying that needs to take place and can't until we remove
the
> old code paths.
>
> It doesn’t look like there has been any changes for this yet - is the plan
> for the old shuffle code to be removed before the branch for 3.6? If so do
> you have this in hand or do you want assistance to get it done in time?

I just got distracted by other things. I should be able to take care of it
now that folks are back from the holidays.

One question -- do you see any regressions that need fixing first? I don't
see any, but I'm curious about others. The silence on this thread didn't
inspire confidence, but perhaps its just that nothing is broken with the
new stuff?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150104/fa6ea97d/attachment.html>

On 4 Jan 2015, at 23:30, Chandler Carruth <chandlerc at gmail.com> wrote:
> On Sun, Jan 4, 2015 at 3:20 PM, Simon Pilgrim <llvm-dev at
redking.me.uk> wrote:
> On 24 Nov 2014, at 17:53, Chandler Carruth <chandlerc at gmail.com>
wrote:
> 
> > I'll be skimming the PRs to see if there are any really critical
regressions, but so far it looks pretty good.
> >
> > If you are actively disabling the new vector shuffling and have some
PR that blocks you, please reply here. Later this week, the flag will go away
unless I hear strenuous objections. There is a really staggering amount of
cleanup and tidying that needs to take place and can't until we remove the
old code paths.
> 
> It doesn’t look like there has been any changes for this yet - is the plan
for the old shuffle code to be removed before the branch for 3.6? If so do you
have this in hand or do you want assistance to get it done in time?
> 
> I just got distracted by other things. I should be able to take care of it
now that folks are back from the holidays.
> 
> One question -- do you see any regressions that need fixing first? I
don't see any, but I'm curious about others. The silence on this thread
didn't inspire confidence, but perhaps its just that nothing is broken with
the new stuff?
No notable regressions, I’m seeing different code but mostly for the better -
although there are a number of vec256 shuffles (mostly lower/upper crossings)
that are rather poor (I think Quentin raised bugs on a couple of these) - but
the old system could be a lot worse. I think the few cases that remain can
easily be dealt with by individual bug reports.

The amount of domain crossing is much lower now - but there are a number of
float shuffles that now use double shuffles instead - fine from a domain point
of view but rather unexpected. IIRC this often appeared in matrix transpose code
- movlhps / movhlps being replaced by unpcklpd / unpckhpd is the one I seem to
remember.

Overall - a massive improvement - thank you!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150105/0c88ec39/attachment.html>

> On Jan 4, 2015, at 4:25 PM, Simon Pilgrim <llvm-dev at redking.me.uk>
wrote:
> 
> 
> On 4 Jan 2015, at 23:30, Chandler Carruth <chandlerc at gmail.com
<mailto:chandlerc at gmail.com>> wrote:
> 
>> On Sun, Jan 4, 2015 at 3:20 PM, Simon Pilgrim <llvm-dev at
redking.me.uk <mailto:llvm-dev at redking.me.uk>> wrote:
>> On 24 Nov 2014, at 17:53, Chandler Carruth <chandlerc at gmail.com
<mailto:chandlerc at gmail.com>> wrote:
>> 
>> > I'll be skimming the PRs to see if there are any really
critical regressions, but so far it looks pretty good.
>> >
>> > If you are actively disabling the new vector shuffling and have
some PR that blocks you, please reply here. Later this week, the flag will go
away unless I hear strenuous objections. There is a really staggering amount of
cleanup and tidying that needs to take place and can't until we remove the
old code paths.
>> 
>> It doesn’t look like there has been any changes for this yet - is the
plan for the old shuffle code to be removed before the branch for 3.6? If so do
you have this in hand or do you want assistance to get it done in time?
>> 
>> I just got distracted by other things. I should be able to take care of
it now that folks are back from the holidays.
>> 
>> One question -- do you see any regressions that need fixing first? I
don't see any, but I'm curious about others. The silence on this thread
didn't inspire confidence, but perhaps its just that nothing is broken with
the new stuff?
> 
> No notable regressions, I’m seeing different code but mostly for the better
- although there are a number of vec256 shuffles (mostly lower/upper crossings)
that are rather poor (I think Quentin raised bugs on a couple of these) - but
the old system could be a lot worse.
I think Simon talks about PR21943, but this should not hold for moving forward.
> I think the few cases that remain can easily be dealt with by individual
bug reports.
I concur.

Just a quick question, did anyone check the differences on i386?
I want to be sure we identified all the problems before we remove the ability to
easily track down regressions.

Thanks,
Q.
> 
> The amount of domain crossing is much lower now - but there are a number of
float shuffles that now use double shuffles instead - fine from a domain point
of view but rather unexpected. IIRC this often appeared in matrix transpose code
- movlhps / movhlps being replaced by unpcklpd / unpckhpd is the one I seem to
remember.
> 
> Overall - a massive improvement - thank you!
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150105/d36148f4/attachment.html>