[llvm-dev] [GSoC 2016] Better Alias Analysis By Default - Mid Term Summary

[George Burgess IV via llvm-dev]

+Hal

The use-case we dropped support for, specifically, was:

```
void foo() {
  int a;
  int *ap = &a;
  int *ap2 = (int*)((char*)NULL + (uintptr_t)&a);
  // now ap and ap2 may alias
}
```

Our justification is that LLVM (specifically, BasicAA) already explicitly
doesn't support this pattern, so we shouldn't have to support it in CFLAA.

On Tue, Jun 21, 2016 at 3:50 PM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Tue, Jun 21, 2016 at 05:29:13PM -0500, Jia Chen via llvm-dev wrote:
> > - [r271322] Remove aliasing relations between GEP pointers and GEP
> indices.
> > Before this patch, CFL-AA will claim that a and b may-alias each other in
> > the following codes:
> >
> > int a[10], b[10];
> > a[N] = ...;
> > b[N] = ...;
> >
> > This seemingly insane behavior was actually there to safeguard certain
> cases
> > where people do crazy stuffs with pointer arithmetics. Later we figured
> out
> > that those crazy behaviors were in fact UB and therefore we could drop
> > support for it.
>
> What exactly is the semantic justification here? I'm asking because
> there are a number of crucial use cases for aliasing global arrayish
> variables behind the compiler like linker sets. We had quite some fun in
> NetBSD with newer GCC introducing breakage by exploiting UB in fun ways.
> It would be nice to avoid breaking valid applications in system/embedded
> land.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160621/34ce8366/attachment.html>