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

[Daniel Berlin via llvm-dev]

On Wed, Apr 12, 2017 at 12:05 PM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> 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>
> 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.
>

I think richard put it better.
The core of the lie is that if two pointers have the same bit value, they
are as good as each other, and must have the same abstract identity
This would in fact, be true, if we could *end* the identity of a pointer
every time a language-level "abstract identity" change occurred.
The problem is this lie is pretty core to the identity of llvm right now.

There is no way to end the lifetime of a scalar value in SSA (and doing so
would break pretty much every nice property it has).

So you can't say:
"lifetime.ended(foo)
<it's not valid to use foo anymore>"


We can use something like  memoryssa (let's call it or orderedmemoryssa,
let's call it), mark the lifetime/identity changes as "ordering" defs, and
get that the two pointers are not noalias because they are not the same
abstract identity as the one marked noalias.

RIght now to hack up noalias we could use the noalias scoping information.
But it's not going to help the other cases we have that do the same thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/1dfefee6/attachment.html>