[llvm-dev] ptrtoint > addrspacecast is disallowed

Harald van Dijk via llvm-dev llvm-dev at lists.llvm.org
Fri Jul 30 09:48:58 PDT 2021


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/44c3e9a0/attachment-0001.html>


More information about the llvm-dev mailing list