<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 30/07/2021 12:27, Kavindu Gimhan
      Zoysa wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CALoJghXuE=Vh1-CzBDybLJE+X5jYDCmWSKbZu+cvwOneMkHFsQ@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div>
            <div dir="ltr" class="gmail_signature"
              data-smartmail="gmail_signature">
              <div dir="ltr">
                <div dir="ltr">
                  <div dir="ltr">
                    <div dir="ltr"><br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <p>The semantics of addrspacecast (<a
                  href="https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction"
                  target="_blank" moz-do-not-send="true"
                  class="moz-txt-link-freetext">https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction</a>)
                are:</p>
              <blockquote>
                <p>The ‘<code class="gmail-notranslate"><span>addrspacecast</span></code>’
                  instruction converts the pointer value <code
                    class="gmail-notranslate"><span>ptrval</span></code>
                  to type <code class="gmail-notranslate"><span>pty2</span></code>.
                  <u>It can be a </u><u><em>no-op cast</em></u><u> or a
                    complex value modification, depending on the target
                    and the address space pair.</u> Pointer conversions
                  within the same address space must be performed with
                  the <code class="gmail-notranslate"><span>bitcast</span></code>
                  instruction. Note that if the address space conversion
                  is legal then both result and operand refer to the
                  same memory location.</p>
              </blockquote>
              <p>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.</p>
            </div>
          </blockquote>
          <div>Thank you, Your explanation helps me to understand this.
            So it is wrong to look at the <b>visitPtrToInt </b>method? </div>
          <div><a
href="https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2046"
              moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/llvm/llvm-project/blob/main/llvm/lib/Transforms/InstCombine/InstCombineCasts.cpp#L2046</a><br>
          </div>
          <div>After going through that method I found that it calls <a
href="https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/Instructions.cpp#L2797"
              moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/llvm/llvm-project/blob/main/llvm/lib/IR/Instructions.cpp#L2797</a>,
            which disallow ptrtoint -> addrspacecast.</div>
        </div>
      </div>
    </blockquote>
    It does not go there directly though. It goes through <span
      class="pl-en">InstCombinerImpl::commonCastTransforms, which checks
    </span><span class="pl-en"><span class="pl-en">InstCombinerImpl::isEliminableCastPair,
        which in turn checks </span></span><span class="pl-en"><span
        class="pl-en"><span class="pl-en">CastInst::isEliminableCastPair.</span></span></span><span
      class="pl-en"><span class="pl-en"><span class="pl-en"></span></span></span><span
      class="pl-en"><span class="pl-en"><span class="pl-en"><span
            class="pl-en"><span class="pl-en"><span class="pl-en"></span></span></span></span></span></span>
    <span class="pl-en"></span><span class="pl-en"><span class="pl-en">InstCombinerImpl::isEliminableCastPair
        has access to the TTI, so my first thought is that when </span></span><span
      class="pl-en"><span class="pl-en"><span class="pl-en"><span
            class="pl-en"><span class="pl-en">CastInst::isEliminableCastPair
              returns 0 to indicate that no target-independent combining
              is possible, </span></span></span></span></span><span
      class="pl-en"><span class="pl-en"><span class="pl-en"><span
            class="pl-en"><span class="pl-en"><span class="pl-en"><span
                  class="pl-en">InstCombinerImpl::isEliminableCastPair
                  could then check whether there is a target-specific
                  combining that can be done and alter the result
                  accordingly.<br>
                </span></span></span></span></span></span></span>
  </body>
</html>