[PATCH] Fix two issues on unaligned 256-bit vector memory access on AVX

[Michael Liao]

BTW, moving concats ahead is that it's too complicated for concats to
handle the case where the input is bitcasted. After moving, only
extract_subvec will handle the case after bitcasting.

Yours
- Michael

On Mon, 2013-03-25 at 16:18 -0700, Nadav Rotem wrote:
> 
> On Mar 23, 2013, at 10:07 PM, Michael Liao <michael.liao at intel.com>
> wrote:
> 
> > Hi All
> > 
> > On Sandybridge, unaligned 256-bit vector memory access needs
> > splitting
> > to avoid higher cache line split penalty. The 1st patch enhances ToT
> > to
> > handle non <4 x i64> vector integer types. 
> 
> 
> You are moving comments and definitions around and it makes it
> difficult to review the code.  
> 
> 
> For the first patch, the "if (Op->getOpcode == BITCAST)" line looks
> okay, but why did you have to move the code that handles concat
> vectors ?
> 
> 
> Regarding the second patch, this change introduces a bug if the
> alignment is zero. 
> 
> 
> > The 2nd patch fixes two
> > alignment calculation issues in ToT. One is a memory access is
> > regarded
> > as aligned if the specified alignment is larger than the natural
> > alignment; the other issue is that the alignment for the high
> > 128-bit
> > vector should be min(16, original alignment) since the pointer is
> > advanced by 16B, a power-of-2 offset.
> > 
> > Test cases are included for each patch.
> > 
> > Thanks for review
> > - Michael
> > 
> > <0001-Enhance-folding-of-extract_subvec-insert_subvec-V1-V.patch><0002-Revise-alignment-calculation-issues-on-256-bit-unali.patch>_______________________________________________
> > llvm-commits mailing list
> > llvm-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>