[Bug target/43814] gcc failed to inline memcpy

["mkuvyrkov at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #5 from Maxim Kuvyrkov <mkuvyrkov at gcc dot gnu.org> 2010-11-12 09:00:56 UTC ---
Richard,

I'm now looking at the failure to inline memcpy() to copy 8 bytes in
==
unsigned long get_ull(const unsigned int *src)
{
    unsigned long long tmp;

    __builtin_memcpy(&tmp, &src[0], 8);
    return tmp;
}
==

One of the underlying problems that prevent inlining of memcpy() is pointer
alignment information for SRC.  Pointer information for SRC is conservatively
initialized in get_ptr_info() and then never made more precise.  With
conservative alignment of 1-byte expand estimates that it would take 8
instructions to copy the data, so a call to memcpy() is expanded instead.

After your patch [*] pointer alignment is primarily handled in tree-ssa-ccp.c. 
For the above example the SSA_NAMEs for both 'src' and 'tmp' are classified as
VARYING, so the alignment stays the conservative 1-byte.

IIUC, the only source of improving alignment information for SRC and TMP in the
above example is type information.  Do you see any other way we could infer
better alignment?

What do you think would be a good place to improve pointer alignment
information for the above case?  CCP doesn't seem like the right place as is
starts gathering and tracking information on the assignments and not from the
function arguments.

[*] http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00831.html

Thanks.