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

[Michael Liao]

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.  

The reason I move them is that align related definitions are only used
in 256-bit load/store splitting. I could move them back if you want.

> 
> 
> 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 code patch with 'min(16, Alignment)' is only entered when
'Alignment != 0'. This is guarded by condition '!IsAligned' of that
branch.

Yours
- Michael
> 
> 
> > 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
>