hfinkel at anl.gov
Mon May 6 11:59:31 PDT 2013
----- Original Message -----
> On 05/06/2013 07:52 AM, Rafael Espíndola wrote:
> > On 6 May 2013 10:29, reed kotler <rkotler at mips.com> wrote:
> >> I want to disable the #APP/#NOAPP for compiler generated inline
> >> asm.
> >> Unfortunately, you can change the string APP,NOAPP, but it still
> >> will put
> >> the "#" there and create
> >> a line.
> >> In the comments it said that the strings were #APP,#NOAPP but
> >> really it's
> >> just the part after the
> >> comment_string=='#'
> >> I'd like to just add a mode flag to AsmPrinter for this.
> >> Any objections?
> > Yes. I don't think we should introduce the notion of "compiler
> > generated inline asm".
> Hi Rafael,
> At this time I have to generate compiler stubs for mips16/32 floating
> point interoperability and I've already implemented it all and I did
> by generating inline assembly in a module pass.
> The whole problem this is solving is complicated and has many cases
> my solution was very clean and easy to understand.
> It's all in the Mips port and I don't have to time or desire to redo
> whole thing right now.
> It's working fine just that it's ugly to see those APP/NOAPP markers.
> I think that I can actually replace the inline assembly for these
> particular stubs with some non inline asm using special calling
> conventions but I don't want to do that right now. I've filed a local
> bug at mips against myself to do that work. There are some further
> issues here but Akira and I think
> it's certainly doable.
> I want to finish testing and checking in what I have and then will
> on improvements later.
> There are many things to still do for mips 16 and this part already
> done and works as in gcc.
> I'm still debugging and writing test cases.
> I think that it's perfectly valid to generate inline assembler and it
> looks 1000 times cleaner than if I tried to do this same work with
> selection DAG.
I hope you don't mind if I play devil's advocate here...
Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of transformations, but late IR-level passes can insert target-specific intrinsics, those can be matched to pseudo instructions, and those pseudo instructions can be expanded (as late as necessary) by a custom inserter. I agree that this may add more boiler-plate work, but it is not immediately obvious why this would be 1000x messier.
> There are other stubs to be created for other parts of the mips32
> So I'd like to get a solution to these ugly APP/NOAPP markers.
> Maybe you would not do things this way but I think it's a perfectly
> valid approach.
> No two people have 100% the same idea of what is best practices.
> The following kind of patch works without adding a mode to asm
> but in general is harder
> for people to use since they have to get a hook to MCAsm in order to
> change the inline_asm_start/end
> strings. (In AsmPrinter) on a per function basis.
> if (OutStreamer.hasRawTextSupport() &&
> So a simple method in AsmPrinter would be the easiest for people to
> It just turns off the APP/NOAPP markers which we should be able to do
> anyway; it's independent of the discussion regarding the goodness or
> of the compiler emitting inline assembly.
> >> Alternately I could change the logic in AsmPrinter to not print a
> >> line if
> >> the inlline asm start/end string is null.
> >> ????
> >> TIA.
> >> Reed
> > Cheers,
> > Rafael
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev