llvm dev - Oct 2015 - crash with vector store

Hello,

I'm working on a pass where I would like to do something to the pointer 
operand of certain store instructions.  (The exact details are not 
relevant to my current problem).

My pass works fine without optimizations but my compiled programs crash 
with -O2.  I've noticed the difference is that with -O2 the bitcode 
contains vector stores.  The resulting -O2 optimized program crashes 
with a SIGSEV invalid address when I run it -- even when I do something 
that I don't think should change the store.

For example, I have two bitcode files: works [1] and broken [2].

The only differences are in broken:
1) the pointer operand of the vector store is bitcasted to int8*
2) then the bitcasted value is passed to a function the returns the same 
pointer
3) then the return value is bitcasted back to the original type
4) then the store's pointer operand is replaced with this final 
bitcasted value (that shouldn't have changed the pointer at all)

Can anyone give me a pointer as to what might be going on?

The core of my problem is that I want to be able to do manipulation of 
the pointer operand of the vector store.  But if I just pass it to a 
function that returns the same pointer my program is crashing.

Thanks,
Scott

[1] http://pastebin.com/raw.php?i=nbmfYZrv
[2] http://pastebin.com/raw.php?i=N83SypdZ
[3] test.c: http://pastebin.com/raw.php?i=RfL1QF7q

On 7 October 2015 at 18:44, carr27 via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> Can anyone give me a pointer as to what might be going on?
I assume you recreated the store in the second example? It looks like
you forgot to copy across the alignment annotation "align 1" from the
old one.

Without that the x86 backend assumes that since the type is a 128-bit
vector, it's allowed to assume the address is aligned and produces a
"movaps" instruction, which aborts since the address isn't
actually
aligned.]

Cheers.

Tim.

> I assume you recreated the store in the second example? It looks like
> you forgot to copy across the alignment annotation "align 1" from
the
> old one.
That was exactly the problem.  Thanks for your help.

-Scott
> On Oct 7, 2015, at 10:07 PM, Tim Northover <t.p.northover at
gmail.com> wrote:
> 
> On 7 October 2015 at 18:44, carr27 via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> Can anyone give me a pointer as to what might be going on?
> 
> I assume you recreated the store in the second example? It looks like
> you forgot to copy across the alignment annotation "align 1" from
the
> old one.
> 
> Without that the x86 backend assumes that since the type is a 128-bit
> vector, it's allowed to assume the address is aligned and produces a
> "movaps" instruction, which aborts since the address isn't
actually
> aligned.]
> 
> Cheers.
> 
> Tim.