llvm dev - Jul 2021 - ptrtoint > addrspacecast is disallowed

> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210730/d420329c/attachment.html>

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>