[PATCH] Introduce __BIGGEST_ALIGNMENT__ macro

[mats petersson]

Would it help to have some sort of test that tries to check the natural
alignment needed for various built in types - including vector types (such
as the ones used by SSE and AVX), and compare that with this constant?

Or are you simply concerned that "this doesn't help much, since it doesn't
fix binaries already produced"?

--
Mats

On 13 December 2014 at 19:51, mats petersson <mats at planetcatfish.com> wrote:

> I don't think the existing binary problem CAN be solved - unless the code
> calls some function to enquire about the alignment, and then uses that.
> That of course assumes first and foremost that there is a suitable API to
> provide this information in the first place.
>
> But having a constant that "if you just recompile, it will be fine" is a
> better solution than "you have to change your constant that you invented
> for your code to n, then recompile". And it gets more interesting when
> architecture A needs alignment of 8, architecture B needs 4, and
> architecture C needs alignment of 16. For portable code, this is quite a
> lot of work - unless you assume "largest of the different values", but
> using 16 can be quite a lot of overhead with many small allocations (linked
> lists and trees with small members, for example).
>
> --
> Mats
>
>
>
> On 13 December 2014 at 19:18, Joerg Sonnenberger <joerg at britannica.bec.de>
> wrote:
>
>> On Sat, Dec 13, 2014 at 06:43:03PM +0000, mats petersson wrote:
>> > If the alignment, then surely "SuitableAlignment" should also change? It
>> > "SuitableAlignment" isn't the right thing to use for "largest
>> alignment",
>> > then perhaps a new member is needed, but I thought that
>> "SuitableAlignment"
>> > was for "The alignment you need to ensure that data is aligned
>> correctly.
>>
>> But such change doesn't help *existing* binaries. We've had such fun in
>> NetBSD with the Unix Domain Socket control message interface before,
>> encoding "maximum alignment" implicitly in the ABI is not fun. That's
>> why I am asking what the future compatibility promises around this
>> interface are.
>>
>> Joerg
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141213/9fed9f7a/attachment.html>