[cfe-dev] Automagic strengthening of alignment of pointer parameters through a cast

[Nemanja Ivanovic via cfe-dev]

Thank you David,

I think based on the statements in the standard, this is undefined
behaviour. UBSan certainly seems to think so.

On Wed, Dec 28, 2016 at 11:27 AM, David Chisnall <
David.Chisnall at cl.cam.ac.uk> wrote:

> On 28 Dec 2016, at 09:31, Nemanja Ivanovic via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> >
> > The natural alignment of vectors on PPC is 16-bytes. The natural
> alignment of
> > int is 4. When clang is emitting the IR for this, it'll use the
> alignment of
> > the result of the cast on the load. So in this case, the alignment is
> unduly
> > strengthened which can produce incorrect code.
>
> I think the fix needs to be a little bit more subtle.  The C standard
> states that it’s undefined behaviour for the result of a cast to be under
> aligned when derererenced, so in the general case if casting from X* to Y*
> and then dereferencing the result, the pointer must have the alignment of
> Y.  In effect, when you cast from int to v4i, you are asserting to the
> compiler that the alignment is correct.  To get the result that you want,
> you should be using the alignas attribute or similar on the destination
> cast.
>
> That said, it looks as if clang always uses natural alignment when it
> means C standard (ABI-defined) alignment, which is a bug.  There probably
> ought to be a hook to allow targets to weaken the alignment guarantees
> provided by a type.
>
> Your patch, as is, would cause regressions on a lot of targets.  Casting a
> char* to an int*, for example, would leave it with 1-byte alignment and if
> the target doesn’t support unaligned accesses for 4-byte values (e.g. some
> MIPS, many GPUs) then you’d get much slower code.  Even on targets such as
> x86, for vectors you’d now be emitting the unaligned variants instead of
> the aligned ones.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161228/48d5d4f5/attachment.html>