[llvm-commits] [PATCH] extend fix to PR12312 to support 256-bit vector

[Michael Liao]

Here is the revised patch after splitting type-legalization patch out.

Thanks for review
- Michael

On Mon, 2012-09-10 at 08:52 -0700, Michael Liao wrote:
> On Mon, 2012-09-10 at 10:38 +0300, Nadav Rotem wrote:
> > Hi, 
> > 
> > The PTEST changes look okay.  However, I would like to see a new LLVM builtin function for checking all-one or all-zero on vectors.  
> 
> Glad to see that happen soon. As discussed in another thread, I'd like
> to see horizontal vector operations are supported efficiently within
> LLVM, such as
> 
> float %s = reduce fadd <N x float> %x ; horizontal fadd reduction
> i32 %m = reduce max <N x i32> %x ; horizontal max reduction
> i1 %c = any <N x i1> %x ; or
> i1 %c = reduce or <N x i1>	; any zero
> i1 %c = all <N x i1> %x ; or
> i1 %c = reduce and <N x i1>	; all ones
> 
> 
> > 
> > Are the changes in LegalizeTypesGeneric related to the ptest changes ?  Can you separate them to a different patch ?
> 
> It's a relevant change as type legalization will transform a bitcast
> from 256-bit vector to 256-bit integer into a vector store followed by a
> series of load. It's inefficient for target with vector support and
> difficult for backend to analyze.
> 
> - michael
> 
> > 
> > Otherwise, LGTM. 
> >   
> > Nadav   
> > 
> > 
> > On Sep 6, 2012, at 9:58 AM, Michael Liao <michael.liao at intel.com> wrote:
> > 
> > > Hi
> > > 
> > > Fix to PR12312 only supports 128-bit vector. This patch extends the
> > > support to 256-bit vector as well. The patch includes 2 major changes:
> > > 
> > > + one change to, when bitcasting 256-bit vector (or wider) to 256-bit
> > > integer, allow type legalization to extract elements instead of storing
> > > whole vector followed by loading each element.
> > >  Suppose a N-bit vector into a N-bit integer. Type legalization will
> > > try cast that N-bit vector into <2 x (N/2)> vector first and extract the
> > > lo/hi part. When N = 128, <2 x (N/2>) is legal. But, when N =256, <2 x
> > > i128> is illegal (on x86) and type legalization falls back to store/load
> > > approach.
> > >  When <2 x (N/2)> is found illegal, this patch tries to check <M x
> > > ExtVT>, where ExtVT is the type which N-bit integer is extended onto,
> > > e.g. on x86, 256-bit integer will be extended to 64-bit integers and we
> > > will try <4 x i64>. If <M x ExtVT> is legal, we will extract elements
> > > from it and build N/2-bit lo/hi parts.
> > > 
> > > + the other change is X86-specific. This patch moves the previous logic
> > > recognizing OR'd tree into IR lowering phase to reduce DAG combination
> > > overhead. In addition, it's enhanced to handle OR'd tree from elements
> > > extracted from 1+ 128-/256-bit vectors. If more than more than input
> > > vectors are found, it will POR first and finally PTEST. Otherwise, just
> > > a single PTEST.
> > > 
> > > Test cases are enhanced with 256-bit vectors.
> > > 
> > > Thanks for review.
> > > 
> > > Yours
> > > - Michael
> > > 
> > > <0001-add-wider-integer-support-for-PR12312.patch>_______________________________________________
> > > llvm-commits mailing list
> > > llvm-commits at cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> > 
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Add-wider-integer-support-for-PR12312.patch
Type: text/x-patch
Size: 14340 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120910/16de4cae/attachment.bin>