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

[Daniel Berlin via llvm-dev]

On Wed, Apr 12, 2017 at 12:19 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

>
>> It seems to me that there are two ways of thinking about this: either the
>> value of a pointer in IR is richer than its bit sequence, in which case
>> replacing p1 with p0 in a block predicated by p0 == p1 is an incorrect
>> transformation if you cannot prove that one pointer was based on the other,
>>
>
> Which would be a non-starter just from the cost of doing so, not to
> mention the allowable optimization you lose :)
>
>> or the value of a pointer in IR is exactly its bit sequence, in which
>> case the code performing the transformation incorrectly updated the IR and
>> a correct transformation would need to somehow remove the noalias from the
>> malloc calls.
>>
>
> Also note, btw, the transformation did not incorrectly update the IR.
The store and the load were never noalias in the first place, becuase they
were *always* talking about different abstract identities than the one that
the malloc calls had.  It's just not expressed in the IR, and it  was not
used to optimize until the other transformations occurred.

That is, with a smart enough optimization code, I could right now,
 directly go from the start code to the end code with the IR as it appeared
in the first example.
We just don't happen to.

Given good enough optimizers, there is no transformation update point to
fix, there is only the missing semantic information that the abstract
identity of the memory being stored and loaded is not the same as the
abstract identity of the pointer returned by malloc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170412/216ee4f0/attachment.html>