This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __builtin_memcpy and alignment assumptions


On Thu, Jan 7, 2016 at 9:05 PM, Steve Ellcey <sellcey@imgtec.com> wrote:
> I have a question about __builtin_memcpy and alignment.  While working on
> MIPS I noticed that this program:
>
> void foo(int *a, int *b)
> {
>         __builtin_memcpy (a, b, 8);
> }
>
> Is generating the following MIPS code (allowing for any alignment):
>
>         lwl     $3,3($5)
>         lwl     $2,7($5)
>         lwr     $3,0($5)
>         lwr     $2,4($5)
>         swl     $3,3($4)
>         swr     $3,0($4)
>         swl     $2,7($4)
>         swr     $2,4($4)
>
> But it seems like it should generate this code which assumes 32 bit alignment,
> since int types need to be 32 bit aligned:
>
>         lw      $3,0($5)
>         lw      $2,4($5)
>         sw      $3,0($4)
>         sw      $2,4($4)
>
> When I look at expand_builtin_memcpy, and I look at the trees for the
> source and destination, they both show pointers pointing to something
> with 32 bit aligned data, but src_align and dest_align are getting set
> to 8 and not to 32, in trying to track this down I get into
> get_pointer_alignment_1 with this tree:
>
>  <ssa_name 0x7f13ac4669d8
>     type <pointer_type 0x7f13ac47c738
>         type <integer_type 0x7f13ac46f690 int public SI
>             size <integer_cst 0x7f13ac46e4c0 constant 32>
>             unit size <integer_cst 0x7f13ac46e4e0 constant 4>
>             align 32 symtab 0 alias set -1 canonical type 0x7f13ac46f690 precision 32 min <integer_cst 0x7f13ac46e7e0 -2147483648> max <integer_cst 0x7f13ac46e800 2147483647>
>             pointer_to_this <pointer_type 0x7f13ac47c738>>
>         unsigned SI size <integer_cst 0x7f13ac46e4c0 32> unit size <integer_cst 0x7f13ac46e4e0 4>
>         align 32 symtab 0 alias set 2 canonical type 0x7f13ac47c738>
>     var <parm_decl 0x7f13ac568080 b>def_stmt GIMPLE_NOP
>
>     version 3
>     ptr-info 0x7f13ac55a1e0>
>
> And when I look at ptr-info (returned by SSA_NAME_PTR_INFO), I see that its
> align value is zero and that is why I get an 8 instead of a 32 for alignment.
>
> The problem is, who/where/when should the ptr-info information get set,
> or am I off base and can I not actually assume 32 bit alignment instead
> of 8 bit alignment in this code?

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).

In theory we could lessen the middle-end restriction for function
parameters or frontends
could insert proper __builtin_assume_aligned calls.

Richard.

> Steve Ellcey
> sellcey@imgtec.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]