Re: [PATCH][v3] GIMPLE store merging pass

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Sep 07, 2016 at 10:19:11AM +0200, Richard Biener wrote:
> > If you want a 64-bit store, you'd need to merge the two, and that would be
> > even more expensive.  It is a matter of say:
> > 	movl $0x12345678, (%rsp)
> > 	movl $0x09abcdef, 4(%rsp)
> > vs.
> > 	movabsq $0x09abcdef12345678, %rax
> > 	movq %rax, (%rsp)
> > vs.
> > 	movl $0x09abcdef, %eax
> > 	salq $32, %rax
> > 	orq $0x12345678, %rax
> > 	movq $rax, (%rsp)
> 
> vs.
> 
>         movq $LC0, (%rsp)

You don't want to store the address, so you'd use
	movq .LC0, %rax
	movq %rax, (%rsp)

> I think the important part to notice is that it should be straight forward
> for a target / the expander to split a large store from an immediate
> into any of the above but very hard to do the opposite.  Thus from a
> GIMPLE side "canonicalizing" to large stores (that are eventually
> supported and well-aligned) seems best to me.

I bet many programs assume that say 64-bit aligned store in the source is
atomic in 64-bit apps, without using __atomic_store (..., __ATOMIC_RELAXED);
So such a change would break that.

	Jakub