[PATCH] Vectorizing Global Structures - Take 2

[Arnold Schwaighofer]

I think what Daniel meant here is that you can have

  struct S { int a[2]; int b[2];}g;
  char *ptr = &g.a[1];
  ++ptr;
  *ptr = …// you are now accessing S.b (without knowing it by just looking at the type of access "char *")

This is all defined behavior in C and a TBAA system would have to make sure it correctly says that ptr might alias &structS.a/b. But this is fine with my envisioned enhanced TBAA because *ptr is an access through a char pointer and an access through a char pointer aliases with any access in a TBAA system for C.

(Although I have to admit, I have not tried to break it for long, so I don't feel comfortable to say I know it is gonna work but only I believe - maybe Daniel knows it won't work - he has way more experience working on Pointer Analysis than I have ;)


On Feb 16, 2013, at 6:57 AM, Renato Golin <renato.golin at linaro.org> wrote:

> On 16 February 2013 00:38, Daniel Berlin <dberlin at dberlin.org> wrote:
> you fall into the "otherwise, the behavior is undefined".
> 
> It would be explicitly valid to convert it to char *, and read it up
> to and through B, but not using the array access operator.
> 
> Unfortunately, "undefined behaviour" is valid C. It means you'll have to compile that without error (possibly a warning), but you're allowed to do whatever you want.
> 
> Clang sometimes remove accesses if they're going to go outside the boundaries (if it can tell) as optimization, as we seen in the Livermore Loops example. GCC vectorizes a loop when the only aliasing possible is with out-of-bounds access (thus getting different results). All that falls into the category of "user error", so both Clang and GCC won't change their behaviour on optimized builds.
> 
> cheers,
> --renato

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130216/32727942/attachment.html>