http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43814
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> 2010-11-12 11:23:51 UTC --- On Fri, 12 Nov 2010, mkuvyrkov at gcc dot gnu.org wrote: > 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. Correct, that's the most conservative thing we can do. > 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? No. It is the C language that makes the promise that src points to memory aligned suitable for unsigned int. As the middle-end has to target multiple languages it can't really assess anything from just looking at pointed-to types (and no part of GCC tries to be correct with that, as an example look at the types the C frontend generates for struct X __attribute__((packed)) { int x; }; void foo (struct X *p, int *q) { memcpy(&p->x, q, 4); } - &p->x will have int * type, not int aligned(1) * type. > 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. I considered infering initial alignment from function argument pointers pointed-to types. But I think that's still dangerous. Also alignment can be infered from dereferences, but that doesn't easily fit into the CCP framework (there's no def for the pointer) and is also dangerous as there is a lot of code out there that simply assumes misaligned accesses are ok. In short, it's not easy. I'd consider the pointer argument thing for 4.6, but would it really help in practice (as opposed to simple artificial testcases)? Richard.
