[llvm-dev] Redundant ptrtoint/inttoptr instructions

[Hal Finkel via llvm-dev]

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.

  -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

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