[llvm-dev] Reducing the number of ptrtoint/inttoptrs that are generated by LLVM

[Chandler Carruth via llvm-dev]

On Mon, Jan 14, 2019 at 5:54 PM Mehdi AMINI <joker.eph at gmail.com> wrote:

>
>
> On Mon, Jan 14, 2019 at 5:44 PM Chandler Carruth <chandlerc at gmail.com>
> wrote:
>
>> On Mon, Jan 14, 2019 at 5:03 PM Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <chandlerc at gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <joker.eph at gmail.com wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>>
>>>>>> While I'm very interested in the end result here, I have some
>>>>>> questions that don't seem well answered yet around pointer subtraction...
>>>>>>
>>>>>> First and foremost - how do you address correctness issues here?
>>>>>> Because the subtraction `A - B` can escape/capture more things.
>>>>>> Specifically, if one of `A` or `B` is escaped/captured, the subtraction can
>>>>>> be used to escape or capture the other pointer.
>>>>>>
>>>>>
>>>>> Isn't escaping supposed to work at the "address ranges" level and not
>>>>> at the pointer value?
>>>>> I mean that if `A` or `B` is escaped/captured, then any pointer that
>>>>> is associated to the same memory range should be considered as "escaped",
>>>>> and thus the subtraction does not seem to leak anything more to me.
>>>>>
>>>>
>>>> I believe this is true for subtracting "inbounds" (to borrow the gep
>>>> terminology), but just as we support non inbounds GEP, we support non
>>>> imbounds subtracting. There it seems like this does escape the other
>>>> global. I know that in the past I've discussed this exact case with
>>>> nlewycky and he believed that to be the case, so I suspect quite a bit of
>>>> LLVM is written under this model. No idea what would be the impact of
>>>> changing it beyond the ability to represent code like the example I gave
>>>> earlier on the thread.
>>>>
>>>
>>> That does not match my current reading of LangRef (admittedly
>>> shallow/imperfect): not having inbounds allows you to form pointers that
>>> are outside of the memory range, however the "result value may not
>>> necessarily be used to access memory though, even if it happens to point
>>> into allocated storage".
>>> Also the "pointer aliasing rules" section mentions: "Any memory access
>>> must be done through a pointer value associated with an address range of
>>> the memory access, otherwise the behavior is undefined".
>>>
>>
>> I think there are still two issues here:
>>
>> 1) Escape of the address doesn't necessarily imply you can access the
>> memory. It can still be an escaped address. It may not *alias* the memory,
>> but that's a different question (confusingly). This means, for example,
>> that a global may still be address-taken even though it cannot be accessed.
>>
>
> I suspect we are out of the LangRef domain, but I'm surprised by this
> definition. Why is it useful to consider such address as "escaping"?
> I'm not an expert on the literature, but I have always encountered the
> notion of escape analysis in relation with aliasing: it isn't the value of
> the pointer that is interesting to consider "escaped" but the memory it is
> pointing to.
>

The use cases I'm aware of relate to the thing I mentioned in my comment. ;]

Imagine you have two functions. If the functions' addreses are escaped,
than even though we may never read or write through those functions, the
addresses must be *different* for different addresses. This is relevant in
inferring things like `unnamed_addr` etc., and can impact constant (and
function) merging semantics.

That said, there may be other uses as well.

Fundamentally, the *address* of an object and *aliasing* properties for
that object are often somewhat independent. You see this with TBAA and
"noalias" or "restrict" semantic models (only alias, not address).

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190114/71229d91/attachment.html>