<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 01/29/2014 04:14 PM, reed kotler
      wrote:<br>
    </div>
    <blockquote cite="mid:52E99974.1090008@mips.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 01/29/2014 10:01 AM, Eric
        Christopher wrote:<br>
      </div>
      <blockquote
cite="mid:CALehDX4TFn2KJjH=AEAUt9oSppWuP9DU89sgnZJHc+hsgzrk2Q@mail.gmail.com"
        type="cite">
        <pre wrap="">On Wed, Jan 29, 2014 at 9:54 AM, Reed Kotler <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:rkotler@mips.com"><rkotler@mips.com></a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">On 01/28/2014 06:29 PM, Eric Christopher wrote:
</pre>
          <blockquote type="cite">
            <pre wrap="">Uhhhh...

-eric

On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:rkotler@mips.com"><rkotler@mips.com></a> wrote:
</pre>
            <blockquote type="cite">
              <pre wrap="">I would like to make the following member of AsmPrinter be protected


void EmitInlineAsm(StringRef Str, const MDNode *LocMDNode = 0,
                        InlineAsm::AsmDialect AsmDialect =
                            InlineAsm::AD_ATT) const;

I have some stubs that I want to emit in MipsAsmParser .

Are there any objections to doing this?

Reed

_______________________________________________
LLVM Developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
            </blockquote>
          </blockquote>
          <pre wrap="">Stubs to emit in MipsAsmPrinter

I think you were one of the people that was against me emitting the inline
asm earlier as part of the IR.

Well, now I am starting to move that to the back end of code generation due
to other issues that were not apparent when I first implemented this mips16
hard float.

Also, it was agreed at that time that it would be better if possible to do
things this way.


</pre>
        </blockquote>
        <pre wrap="">Why not just note that you need to emit the functions as you output
and then emit them during MC?

-eric
</pre>
      </blockquote>
      Let me go back one step...<br>
      <br>
      You are saying that instead of using EmitRawText, that I try and
      do this with the higher level AsmPrinter methods.<br>
      <br>
      Here is a little snipped that does not even include instructions:<br>
      <br>
         
OutStreamer.EmitRawText("\t.section\t.mips16.call.fp"+Twine(Symbol)+",\"ax\",@progbits");<br>
          OutStreamer.EmitRawText(".align 2");<br>
          OutStreamer.EmitRawText(".nomips16");<br>
          OutStreamer.EmitRawText(".nomicromips");<br>
          OutStreamer.EmitRawText("\t.ent\t__call_stub_fp_" +
      Twine(Symbol));<br>
          OutStreamer.EmitRawText("\t.type\t__call_stub_fp_" +
      Twine(Symbol) + ", @function");<br>
          OutStreamer.EmitRawText("\t__call_stub_fp_" + Twine(Symbol) +
      ":");<br>
          OutStreamer.EmitRawText("\t.size  __call_stub_fp_" +
      Twine(Symbol) +<br>
                                  ", .-__call_stub_fp_" +
      Twine(Symbol));<br>
          OutStreamer.EmitRawText("\t.end  __call_stub_fp_" +
      Twine(Symbol));<br>
      <br>
      (I have other code that generates the exact instructions).<br>
      <br>
      Here is the code it wants to generate:<br>
      <br>
          .globl    __floatdidf<br>
          # Stub function to call double __floatdidf ()<br>
          .section    .mips16.call.fp.__floatdidf,"ax",@progbits<br>
          .align    2<br>
          .set    nomips16<br>
          .set    nomicromips<br>
          .ent    __call_stub_fp___floatdidf<br>
          .type    __call_stub_fp___floatdidf, @function<br>
      __call_stub_fp___floatdidf:<br>
          move    $18,$31<br>
          jal    __floatdidf<br>
          mfc1    $2,$f0<br>
          mfc1    $3,$f1<br>
          jr    $18<br>
          .size    __call_stub_fp___floatdidf,
      .-__call_stub_fp___floatdidf<br>
          .end    __call_stub_fp___floatdidf<br>
          .globl    __mips16_muldf3<br>
          .globl    __mips16_truncdfsf2<br>
      <br>
      <br>
      This requires a lot of pseudo ops.<br>
      <br>
      <br>
      <br>
       <br>
    </blockquote>
    This stub comes up when I realize that we are compiling mips16 and
    the compiler is emitting a call to _floatdidf<br>
    There are several of these functions that cause problems for mips16.<br>
    <br>
    This function, when it comes from the c++ linking, does not properly
    wrap this as a mips16 function.<br>
    <br>
    I need to create this function that the linker will substitute for
    the call to _floatdidf which, in this case, calls _floatdidf and
    then moves the return value from<br>
    floating point f0 and f1 into integer registers $2 and $3<br>
    <br>
    <br>
  </body>
</html>