<div dir="ltr">Thanks for the pointer Mandeep!<br></div><div class="gmail_extra"><br><div class="gmail_quote">2018-07-10 19:00 GMT+02:00 Grang, Mandeep Singh via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Take a look at Alex's review comments for
      <a class="m_3495980037324284025moz-txt-link-freetext" href="https://reviews.llvm.org/D45395" target="_blank">https://reviews.llvm.org/<wbr>D45395</a>. I had similar questions while
      implementing tail call lowering for RISCV.</p>
    <p>--Mandeep<br>
    </p><div><div class="h5">
    <br>
    <div class="m_3495980037324284025moz-cite-prefix">On 7/10/2018 9:51 AM, Roger Ferrer
      Ibáñez via llvm-dev wrote:<br>
    </div>
    </div></div><blockquote type="cite"><div><div class="h5">
      
      <div dir="ltr">
        <div>H all,<br>
        </div>
        <div><br>
        </div>
        <div>I'm looking at generating PIC code for RISC-V in the
          context of Linux. Not sure if anyone is working on this
          already, any inputs are very welcome.</div>
        <div><br>
        </div>
        <div>I'm now looking at function calls which in the RISCV
          backend are represented via two pseudoinstructions RISCV::TAIL
          and RISCV::CALL.<br>
        </div>
        <div><br>
        </div>
        <div>Currently those pseudos are lowered in MCCodeEmitter. They
          are expanded into AUIPC and JALR instructions and the first
          one needs a relocation, which for a static reloc model is
          R_RISCV_CALL but for PIC code should be R_RISCV_CALL_PLT.<br>
        </div>
        <div><br>
        </div>
        <div>The problem I find is that at this point it is too late to
          tell the exact relocation needed: as far as I can tell there
          is no way to determine the relocation model. Perhaps this is
          on purpose and the MCCodeEmitter should not have that
          knowledge. Or maybe not and it is just a matter to "push" a
          TargetMachine to it, but the way the class is constructed does
          not look like this approach is workable.<br>
        </div>
        <div><br>
        </div>
        <div>So I was considering lowering these pseudo-instructions in
          AsmPrinter instead. There I can tell the exact kind of the
          MCOperand I want thanks to the fact that the AsmPrinter is
          constructed with a TargetMachine.</div>
        <div><br>
        </div>
        <div>That said perhaps there are extra constraints that require
          doing the lowering in MCCodeEmitter, unfortunately I can't
          tell exactly what is the advantage of lowering that late.<br>
        </div>
        <div><br>
        </div>
        <div>These pseudos are marked as isCodegenOnly = 0 so if I lower
          them in AsmPrinter my understanding is that now I have to
          change them to isCodegenOnly = 1 and then teach AsmParser to
          recognize them (I would need to use the reloc model there
          too). Does this make sense?</div>
        <div><br>
        </div>
        <div>Alternatively I was considering adding two new pseudos like
          RISCV::CALL_PLT and RISCV::TAIL_PLT and also lower them at
          MCCodeEmitter. But this looks a bit too bulky to me and I
          think I would still have the issue that the "call" and "tail"
          pseudos in the assembler would need some extra magic (i.e.
          when assembling a "call" pseudoinstruction with -fPIC) so they
          don't end being parsed as the non-PIC counterparts. I might be
          wrong here though.<br>
        </div>
        <div><br>
        </div>
        <div>Is this reasonable or there are other downsides to consider
          here?</div>
        <div><br>
        </div>
        <div>Thank you very much,<br>
        </div>
        <div><br>
          -- <br>
          <div class="m_3495980037324284025m_2748210212751063545gmail_signature" data-smartmail="gmail_signature">Roger Ferrer Ibáñez<br>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="m_3495980037324284025mimeAttachmentHeader"></fieldset>
      <br>
      </div></div><pre>______________________________<wbr>_________________
LLVM Developers mailing list
<a class="m_3495980037324284025moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a class="m_3495980037324284025moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Roger Ferrer Ibáñez<br></div>
</div>