This is the mail archive of the
mailing list for the GCC project.
Re: __attribute__ aligned could be more efficient
- From: Mason <slash dot tmp at free dot fr>
- To: Jedrzej Dudkiewicz <jedrzej dot dudkiewicz at gmail dot com>
- Cc: GCC help <gcc-help at gcc dot gnu dot org>
- Date: Sun, 29 Mar 2015 21:28:09 +0200
- Subject: Re: __attribute__ aligned could be more efficient
- Authentication-results: sourceware.org; auth=none
- References: <55182ED0 dot 4020602 at free dot fr> <CABJqhQOCD3hPuEhsGMZCofV3tQYEgDXBZWFhQtuf_v8M5gwWJg at mail dot gmail dot com>
On 29/03/2015 20:43, JÄdrzej Dudkiewicz wrote:
> I think that sizeof(struct bar2) equal 192 is pretty obvious. Size of
> struct foo2 is 128 bytes and after that comes 4/8 bytes of int. This
(Out of curiosity, how many gcc targets have a 64-bit int?
I suspect the answer is "zero or fewer".)
> means that size of struct foo2 is 132/136, but requested alignment is
> 64 bytes, so alignment of bar2 must be also 64 bytes. This means that
> if array of bar2 structures is created, each of them must start at 64
> byte boundary. 128 is out of question, but 192 is fine, since it's
> nearest value divisible by 64. So 192 bytes it is.
> Correct me if I'm wrong.
It is obvious to you that the layout for bar2 is:
s(80) + pad(48) + int(4) + pad(60)
It seems to me that there is another possible layout for bar2:
s(80) + int(4) + pad(44) = 128 bytes
The problem then would be that struct foo2 pointers might either
point to a "stand-alone" foo2 -- s(80) + pad(48) -- or to a bar2
"inner struct" (one with the int before the padding).
If gcc generates code that leaves the padding untouched, then
the same code works with both variants, and my suggestion would
be valid. Or did I get something wrong?