[Bug target/43814] gcc failed to inline memcpy

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-04 18:49:34 UTC ---
On Sat, 4 Dec 2010, mkuvyrkov at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
> 
> --- Comment #9 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> 2010-12-04 18:09:15 UTC ---
> (In reply to comment #8)
> 
> > In the end we _should_ be able to use alignment information of the
> > types used at the access (that's also more reliable as compared to
> > use alignment information from pointer argument types).
> > 
> > But we already do that in MEM_REF expansion:
> > 
> >         align = MAX (TYPE_ALIGN (TREE_TYPE (exp)),
> >                      get_object_alignment (exp, BIGGEST_ALIGNMENT));
> 
> Indeed.  SRC will be considered 4-byte aligned in
> ==
> unsigned long long get_ull(const unsigned int *src)
> {
>     unsigned long long tmp;
> 
>     tmp = src[0];

Because here the C language specifies that *src has to be properly
aligned.

>     return tmp;
> }
> ==
> , but only 1-byte aligned in
> ==
> unsigned long long get_ull(const unsigned int *src)
> {
>     unsigned long long tmp;
> 
>     __builtin_memcpy(&tmp, &src[0], 8);

And memcpy has to deal with unaligned memory.

>     return tmp;
> }
> ==
> 
> It seems we should really use for MEM_REFs
> ==
> align = get_pointer_alignment (exp, BIGGEST_ALIGNMENT);
> ==
> without relying on type alignment.  Unfortunately, that will worsen code
> generation even more.

That was what I did originally ...