[llvm-dev] Potential issue with noalias @malloc and @realloc

[Daniel Berlin via llvm-dev]

On Tue, Apr 11, 2017 at 6:58 PM, Flamedoge <code.kchoi at gmail.com> wrote:

> >> For now, the only sane solution IMHO, is to say that no alias implies
> >> pointer inequality, regardless of the standards. Because the above can
> >> occur in any situation noalias exists but they are allowed to be pointer
> >> equal (as mentioned, it's trivial to make this happen in TBAA).
>
> >Just to be clear, you're suggesting that we no longer mark malloc's
> >return value as noalias?
>
> CMIIW, I believe the suggestion was treat p0 as unequal to p1 even under
> runtime check if p0 has NoAlias relation with p1. This will at least make
> ie. GVN to treat as if p0 and p1 aren't equal even if bits are, preventing
> transformation of p1 to p0, thus preventing reordering. I'm not a huge fan
> of this solution, and is quite hacky to GVN and pretty much to all the
> transformation passes :(.
> The root cause is quite clear; you cannot assume malloc'd ptrs to have
> No-Alias without flow-sensitive, "lifetime" analysis.
>
>
Apparently i was really unclear:
Making GVN do this would lose a tremendous amount of optimization.
You'd be better off turning off noalias than doing this.

I would actually just accept that this sucks and move on for now :P
Or modify clang to using the scoped noalias and solve the perofrmance bugs
we have with that representation.

Long term, we need well defined and real lifetime start/end information
that is semantically relevant, not just optional metadata.

(Or we need standards to stop making the lifetimes and aliasing issues
ridiculously complex :P)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170411/2b3382c8/attachment.html>