[llvm-dev] ptrtoint > addrspacecast is disallowed

[Kavindu Gimhan Zoysa via llvm-dev]

Thank you, I got it.

Kavindu Gimhan Zoysa,
BSc(Hons) | ENTC | UoM,
ATL | WSO2

GitHub <https://github.com/KavinduZoysa> LinkedIn
<https://www.linkedin.com/in/kavindu-gimhan-zoysa-85939a122/> Medium
<https://medium.com/@kavindugimhanzoysa>


On Fri, 30 Jul 2021 at 22:19, Harald van Dijk <harald at gigawatt.nl> wrote:

> On 30/07/2021 12:27, Kavindu Gimhan Zoysa wrote:
>
>
> The semantics of addrspacecast (
>> https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction) are:
>>
>> The ‘addrspacecast’ instruction converts the pointer value ptrval to
>> type pty2. *It can be a **no-op cast** or a complex value modification,
>> depending on the target and the address space pair.* Pointer conversions
>> within the same address space must be performed with the bitcast
>> instruction. Note that if the address space conversion is legal then both
>> result and operand refer to the same memory location.
>>
>> So whether it is valid for instcombine to optimise your example depends
>> on the target. It would be wrong for instcombine to unconditionally
>> optimise this to i64 3098316506530080114. It might be possible to extend it
>> to optimise this when the optimisation is valid by getting extra
>> information from the target, there is a isNoopAddrSpaceCast function
>> already that can be used to determine whether it is valid, but the function
>> you are looking at is target-independent, it cannot get target info. It
>> will require some thought on the design.
>>
> Thank you, Your explanation helps me to understand this. So it is wrong to
> look at the *visitPtrToInt *method?
>
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2046
> After going through that method I found that it calls
> https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/Instructions.cpp#L2797,
> which disallow ptrtoint -> addrspacecast.
>
> It does not go there directly though. It goes through InstCombinerImpl::commonCastTransforms,
> which checks InstCombinerImpl::isEliminableCastPair, which in turn checks
> CastInst::isEliminableCastPair. InstCombinerImpl::isEliminableCastPair
> has access to the TTI, so my first thought is that when CastInst::isEliminableCastPair
> returns 0 to indicate that no target-independent combining is possible, InstCombinerImpl::isEliminableCastPair
> could then check whether there is a target-specific combining that can be
> done and alter the result accordingly.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210730/e0f1fae8/attachment.html>