__builtin_memcpy and alignment assumptions

Paul_Koning@Dell.com Paul_Koning@Dell.com
Fri Jan 8 17:29:00 GMT 2016


> On Jan 8, 2016, at 6:32 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> 
> On Fri, Jan 08, 2016 at 12:24:49PM +0100, Eric Botcazou wrote:
>>> See some existing PR.  The GCC middle-end cannot assume that pointers
>>> are aligned according to their type (while at least the C language would
>>> support that notion).
>> 
>> Only on x86.  It could (and used to) do it on strict-alignment architectures.
> 
> I think we only assume it if the pointer is actually dereferenced, otherwise
> it just breaks too much code in the wild.  And while memcpy dereferences, it
> dereferences it through a char * cast, and thus only the minimum alignment
> is assumed.

Is the char* cast actually part of the definition of memcpy?  

The fact that memcpy doesn't make use of the known alignment is a rather unfortunate issue (I'd call it a defect); it results in clearly inferior code on strict-alignment machines when the alignment is in fact clearly known.

If it really is necessary to say that memcpy is defined to behave as if it had a cast to char* in its implementation, it would still be useful -- and obviously valid -- to rely on the greater alignment when there is other code in the block that uses it.  And it would be helpful to have a way in the source program to say "I want you to rely on the type alignment".

	paul



More information about the Gcc mailing list