[llvm-dev] Redundant ptrtoint/inttoptr instructions

[Hal Finkel via llvm-dev]

On 7/2/20 12:09 PM, Hal Finkel via llvm-dev wrote:
>
> My general feeling is this: No optimizations should be creating 
> int2ptr/ptr2int. We really need to fix them all. They should use 
> pointer casts and i8* GEPs. This has, unfortunately, been a problem 
> for a long time. As Johannes says, optimizing int2ptr/ptr2int is very 
> tricky. In part, becaue all dependencies, including implicit control 
> dependencies, end up being part of the resulting aliasing based-on 
> chain, and we have a set of bug reports discussing this is great detail.
>

See, for example, https://bugs.llvm.org/show_bug.cgi?id=34548

  -Hal


>  -Hal
>
> On 7/2/20 11:59 AM, Johannes Doerfert via llvm-dev wrote:
>>
>> Optimizing int2ptr + ptr2int (or vice versa) is tricky business.
>>
>> I would prefer it to be outside SROA, I think.
>>
>>
>> We should be *very* careful and restrictive about it.
>>
>> My initial thought is that the pattern below can be optimized
>>
>> but I haven't spend too much time on it.
>>
>>
>> ~ Johannes
>>
>>
>> On 7/2/20 11:26 AM, Alexey Zhikhartsev via llvm-dev wrote:
>>> Hi all,
>>>
>>> We noticed a lot of unnecessary ptrtoint instructions that stand in way of
>>> some of our optimizations; the code pattern looks like this:
>>>
>>> bb1:
>>>    %int1 = ptrtoint %struct.s* %ptr1 to i64
>>>
>>> bb2:
>>>    %int2 = ptrtoint %struct.s* %ptr2 to i64
>>>
>>> %bb3:
>>>    %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ]
>>>    %ptr = inttoptr i64 %phi.node to %struct.s*
>>>
>>> In short, the pattern above arises due to:
>>> 1. InstCombine introducing a bitcast while performing a canonicalization in
>>> combineLoadToOperationType() [1]
>>> 2. GVN performing "load coercion" and replacing a load with a ptrtoint
>>> (ptrtoint is due to the bitcast)
>>> 3. SROA replacing store- and load-instructions with phi nodes.
>>>
>>> The question is: is it a good idea to clean ptrtoint/inttoptr instructions
>>> inside SROA or should it be done higher in the pass pipeline? More details
>>> below.
>>>
>>> The canonicalization in instruction combining is the root cause of the
>>> problem, more information about the actual transformation and motivation
>>> behind it can be found in this RFC [2]. Based on our experiments, getting
>>> rid of the canonicalization reduces the number of ptrtoint instructions by
>>> 16% and inttoptr instructions by 25%. However, it seems that overall, LLVM
>>> benefits from the canonicalization and, at least back in 2015, many people
>>> supported adding it to LLVM. So, I would like to find a way to keep it
>>> while removing the ptrtoint-s that are unnecessary, and doing clean-up in
>>> SROA is a straightforward way to achieve that.
>>>
>>> What does everybody think?
>>>
>>> Thanks,
>>> Alexey
>>>
>>> [1] combineLoadToOperationType()
>>> https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineLoadStoreAlloca.cpp#L556
>>> [2] [LLVMdev] RFC: Missing canonicalization in LLVM
>>> http://lists.llvm.org/pipermail/llvm-dev/2015-January/080956.html
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> llvm-dev at lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20200702/73a044a6/attachment.html>