llvm dev - Aug 2013 - [LLVMdev] vector type legalization

Hi Nadav,

From: Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>>
Date: Monday, 12 August, 2013 1:59 PM
To: Paul Redmond <paul.redmond at intel.com<mailto:paul.redmond at
intel.com>>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at
cs.uiuc.edu>>
Subject: Re: [LLVMdev] vector type legalization

This is a bug in the implementation of WidenVecRes_Binary.  On line 1546 it
assumes that “Widen” is the last phase of type-legalization and we check if the
result is a legal type. But actually we want to continue and promote the
elements of the vector.  In other cases we may want to widen (to the next power
of two) and later split in half because the vector is too big.

Thanks for the tip. I modified WidenVecRes_Binary match
WidenVecRes_{Unary/Ternary} and it does the promotion and generates much better
code. Why is WidenVecRes_Binary so much more complicated than the Unary/Binary
functions? None of the operations in the cases for WidenVecRes_Binary seem any
more special then the operations that use WidenVecRes_Unary..

paul


On Aug 12, 2013, at 10:46 AM, Redmond, Paul <paul.redmond at
intel.com<mailto:paul.redmond at intel.com>> wrote:

Hi Nadav,

On 2013-08-12 12:59 PM, "Nadav Rotem" <nrotem at
apple.com<mailto:nrotem at apple.com>> wrote:

Hi Paul,

You can read about it here:
http://blog.llvm.org/2011/12/llvm-31-vector-changes.html

Hi,

I am trying to understand how vector type legalization works. In
particular, I'm looking at i8 vector types on x86 (with sse42 features)

v3i8 gets widened to v4i8 and then operations get unrolled (scalarized)
because v4i8 is not a legal type whereas v4i8 gets

This does not sound right.   v3i8 -> v4i8 is okay. But the next step
should be v4i8 -> v4i32.  The operation nay be scalarized in the vector
legalization phase.

What I'm looking at is a v3i8 add. In DAGTypeLegalizer::WidenVecRes_Binary
the operation gets scalarized (DAG.UnrollVector). The input N is
"0x51c1d60: v3i8 = add 0x51c1860, 0x51c1c60 [ORD=5] [ID=0]" and the
WidenVT is v4i8. The code ends up in the NumElts == 1 path which causes
scalarization.

The debug dump shows "Widen node result 0: 0x563dd20: v3i8 = add
0x563d820, 0x563dc20 [ORD=5] [ID=0]". To me it doesn't look like
it's
possible to both widen and promote an operation..

Paul


promoted to v4i32. Why doesn't v3i8 (or even v4i8) get widened to
v16i8? Alternatively, v3i8 could be widened to v4i8 then promoted to
v4i32 but this doesn't happen either.

Can anyone provide some insight into why vector type legalization works
the way it does?

Thanks,
paul

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On Aug 12, 2013, at 1:47 PM, Redmond, Paul <paul.redmond at intel.com>
wrote:
> Thanks for the tip. I modified WidenVecRes_Binary match
WidenVecRes_{Unary/Ternary} and it does the promotion and generates much better
code. Why is WidenVecRes_Binary so much more complicated than the Unary/Binary
functions? None of the operations in the cases for WidenVecRes_Binary seem any
more special then the operations that use WidenVecRes_Unary..
I am not sure :) 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130812/4bf2a7f5/attachment.html>

From: Nadav Rotem <nrotem at apple.com<mailto:nrotem at apple.com>>
Date: Monday, 12 August, 2013 4:52 PM
To: Paul Redmond <paul.redmond at intel.com<mailto:paul.redmond at
intel.com>>
Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu<mailto:llvmdev at
cs.uiuc.edu>>
Subject: Re: [LLVMdev] vector type legalization


On Aug 12, 2013, at 1:47 PM, Redmond, Paul <paul.redmond at
intel.com<mailto:paul.redmond at intel.com>> wrote:

Thanks for the tip. I modified WidenVecRes_Binary match
WidenVecRes_{Unary/Ternary} and it does the promotion and generates much better
code. Why is WidenVecRes_Binary so much more complicated than the Unary/Binary
functions? None of the operations in the cases for WidenVecRes_Binary seem any
more special then the operations that use WidenVecRes_Unary..

I am not sure :)

The reason is special handling for DIV and REM which can trap. The
TargetLowering function canOpTrap is only used in WidenVecRes_Binary and the
default behaviour returns true for the DIV and REM ops (no target seems to
overload this behaviour). The Unary and Ternary functions just assume those
operations don't trap.

An easy fix is to simply split WidenVecRes_Binary into two functions—one that
keeps the behaviour of handling ops that trap and one that assumes no traps.
I'll prepare a patch.

paul