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.