[PATCH] Introduce __BIGGEST_ALIGNMENT__ macro

[mats petersson]

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.

And surely it's better to have an official way to expose "what the compiler
thinks is good alignment", than to have a hard-coded constant of "4" or
"16" or whatever (ok, it may be a "const size_t my_alignment = n;`" or
"#define MY_ALIGNMENT n" in the source, but it's something the programmer
of that particular code thought was good, possibly without considering
future changes in system architecture [Or when porting to a different
architecture].

(I think it was introduction of SSE that enforced new alignment, but that
wasn't particularly useful for general purpose programming, so it was only
once SSE2 with it's improved set of instructions that it became useful to
let the compiler pick SSE(2) instructions, but that's a detail, and nothing
to do with my patch.... :) )

--
Mats

On 13 December 2014 at 18:06, Joerg Sonnenberger <joerg at britannica.bec.de>
wrote:

> On Sat, Dec 13, 2014 at 05:51:27PM +0000, mats petersson wrote:
> > Add a predefined macro reflecting the largest alignment required by
> > the archiecture, in bytes. This is useful for allocator designs that
> > need to know the system alignment requirements. It reflects the
> > TargetInfo.SuitableAlignment, converted to bytes (using CharWidth).
>
> The one issue I have with this is that exports data that may change in
> the future. What is the stability guarantee for it? Consider i386 -- for
> a very long time, nothing required more than 32bit alignment. Only the
> introduction of SSE2 changed that.
>
> 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/58a7ba07/attachment.html>