On 01/28/2014 06:29 PM, Eric Christopher wrote:> Uhhhh... > > -eric > > On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >> 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 >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevStubs 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.
On Wed, Jan 29, 2014 at 9:54 AM, Reed Kotler <rkotler at mips.com> wrote:> On 01/28/2014 06:29 PM, Eric Christopher wrote: >> >> Uhhhh... >> >> -eric >> >> On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >>> >>> 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 >>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > 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. > >Why not just note that you need to emit the functions as you output and then emit them during MC? -eric
On 01/29/2014 10:01 AM, Eric Christopher wrote:> On Wed, Jan 29, 2014 at 9:54 AM, Reed Kotler <rkotler at mips.com> wrote: >> On 01/28/2014 06:29 PM, Eric Christopher wrote: >>> Uhhhh... >>> >>> -eric >>> >>> On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >>>> 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 >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> 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. >> >> > Why not just note that you need to emit the functions as you output > and then emit them during MC? > > -ericI'll take a look at that. I've added what I need to Mips Asm Printer already; the only issue being that I'm not covering the direct object emitter case but we don't have direct object emitter for Mips16 anyway at this time. This inline asm interface would have trumped that issue. I need to push this upstream to fix some regressions caused by us moving to the tip of tree test-suite; we've been using an old version for a long time that we custom modified but now are using tip of tree. If there is a simple way to do this in MC I will consider moving things there but after this current push which is urgent for us. I have some other issues to track down in mips64 related to this test-suite upgrade that are also higher priority for me at this time. The list of needed stubs is a "per module list". So I need to process the results of all functions and then emit them at the end, because there can be duplicates in the particular case that prompted me to move things. There is some nuttiness in mips16 floating point (well the whole thing is nutty but this is new nuttiness) and when you link with clang++ as opposed to gcc, it reverses two of the standard libraries which causes the wrong version of certain libc intrinsics to get linked in; they need special stubs . Certain parts of test-suite makefiles use c++ (clang++) to link even though the code is C and in the past our custom scripts used C (clang) . Reed
On 01/29/2014 10:01 AM, Eric Christopher wrote:> On Wed, Jan 29, 2014 at 9:54 AM, Reed Kotler <rkotler at mips.com> wrote: >> On 01/28/2014 06:29 PM, Eric Christopher wrote: >>> Uhhhh... >>> >>> -eric >>> >>> On Tue, Jan 28, 2014 at 4:56 PM, reed kotler <rkotler at mips.com> wrote: >>>> 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 >>>> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> 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. >> >> > Why not just note that you need to emit the functions as you output > and then emit them during MC? > > -ericLet me go back one step... You are saying that instead of using EmitRawText, that I try and do this with the higher level AsmPrinter methods. //Here is a little snipped that does not even include instructions: OutStreamer.EmitRawText("\t.section\t.mips16.call.fp"+Twine(Symbol)+",\"ax\", at progbits"); OutStreamer.EmitRawText(".align 2"); OutStreamer.EmitRawText(".nomips16"); OutStreamer.EmitRawText(".nomicromips"); OutStreamer.EmitRawText("\t.ent\t__call_stub_fp_" + Twine(Symbol)); OutStreamer.EmitRawText("\t.type\t__call_stub_fp_" + Twine(Symbol) + ", @function"); OutStreamer.EmitRawText("\t__call_stub_fp_" + Twine(Symbol) + ":"); OutStreamer.EmitRawText("\t.size __call_stub_fp_" + Twine(Symbol) + ", .-__call_stub_fp_" + Twine(Symbol)); OutStreamer.EmitRawText("\t.end __call_stub_fp_" + Twine(Symbol)); (I have other code that generates the exact instructions). Here is the code it wants to generate: .globl __floatdidf # Stub function to call double __floatdidf () .section .mips16.call.fp.__floatdidf,"ax", at progbits .align 2 .set nomips16 .set nomicromips .ent __call_stub_fp___floatdidf .type __call_stub_fp___floatdidf, @function __call_stub_fp___floatdidf: move $18,$31 jal __floatdidf mfc1 $2,$f0 mfc1 $3,$f1 jr $18 .size __call_stub_fp___floatdidf, .-__call_stub_fp___floatdidf .end __call_stub_fp___floatdidf .globl __mips16_muldf3 .globl __mips16_truncdfsf2 This requires a lot of pseudo ops. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140129/a15be380/attachment.html>