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

[Hal Finkel via llvm-dev]

On 04/11/2017 09:19 PM, Daniel Berlin via llvm-dev wrote:
>
>
> On Tue, Apr 11, 2017 at 7:02 PM, Daniel Berlin <dberlin at dberlin.org 
> <mailto:dberlin at dberlin.org>> wrote:
>
>
>
>         > It would require semantic changes to llvm ir to fix this to
>         properly
>         > express object lifetimes that is compatible with all the
>         random babble
>         > standards have written down :)
>         > 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?
>
>
>     Actually, i'd suggest just letting it be a bug :)
>     That's what other compilers seem to do.
>     You could hack around this in clang by using the !alias.scope and
>     !noalias form, and not attaching the scope past the lifetime end.
>
>     But we don't optimize that.
>
>
> (by this i mean it's only used by memdep).
>
> I believe hal also has a noalias instrinsic proposal that would have 
> been useful here.
>
> But thinking harder, it has the same problem because there is no way 
> to end the lifetime of something in ssa, and thus, iif  do
> a1 = llvm.noalias(a)
> b1 = llvm.noalias(b)
> if (a1 == b1)
>   oh crap

Yep; doesn't help.

>
> So we can't use it to specify the lifetimes here.
>
>

I feel like this is the perfect place for a pithy quote on self 
deception. The core problem here is that we allow the optimizer to rely 
on a lie (that all memory from malloc, and other noalias functions, is 
distinct). This, of course, is not really true. The consequence seems to 
be that if you write code that can observe the fallacy of this 
assumption - *even dead code* -  then the model breaks. Dead code can 
observe things, in this sense, I suppose, if there are no data 
dependencies or side effects that prevent the optimizer from making it 
speculatively live.

  -Hal

>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/abfd3ea1/attachment.html>