Hi Hal, 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. > > -HalI should probably qualify this with "1000 times messier for me" :) In this case the whole problem fit neatly in a simple IR level module pass. I had to create an alternate calling convention for one part but otherwise this IR pass made an otherwise very messy problem easy to implement. Reed>> There are other stubs to be created for other parts of the mips32 >> port. >> >> 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 >> printer >> 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() && >> MAI->getInlineAsmStart()[0]) >> OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ >> MAI->getInlineAsmStart()); >> >> So a simple method in AsmPrinter would be the easiest for people to >> use. >> >> 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 >> not >> of the compiler emitting inline assembly. >> >> >> Reed >> >> >> >>>> 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 >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>
On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote:> Hi Hal, > > > 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'm pretty sure you're the only one who thinks this. What's so complicated about doing this either at selection dag or MI lowering time? -eric>> 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. >> >> -Hal > > I should probably qualify this with "1000 times messier for me" :) > > In this case the whole problem fit neatly in a simple IR level module pass. > > I had to create an alternate calling convention for one part but otherwise > this IR > pass made an otherwise very messy problem easy to implement. > > Reed > > >>> There are other stubs to be created for other parts of the mips32 >>> port. >>> >>> 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 >>> printer >>> 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() && >>> MAI->getInlineAsmStart()[0]) >>> OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ >>> MAI->getInlineAsmStart()); >>> >>> So a simple method in AsmPrinter would be the easiest for people to >>> use. >>> >>> 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 >>> not >>> of the compiler emitting inline assembly. >>> >>> >>> Reed >>> >>> >>> >>>>> 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 >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>> > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 05/06/2013 04:23 PM, Eric Christopher wrote:> On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> Hi Hal, >> >> >> 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'm pretty sure you're the only one who thinks this. What's so > complicated about doing this either at selection dag or MI lowering > time? > > -eric >This pass I did was very easy for me to do in IR. It took maybe a week to write which included time for analysis (what I'm doing is mimicking gcc and how it does this is not documented). There are lots of cases to handle and it took very little code to do it. It's possible to even eliminate half of the code by adding a new calling convention which I intend to do at a later time. Someone else might have done this a different way (maybe even everyone but me :) ) When I check it in you can look at it and maybe advise me for future reference. That would be great to know a better way. There are other stubs we need to add for mips but these are the ones for mips16/mips32 floating point interoperability. There is also code inserted to return values in both integer and floating point registers (for the same return) so that depending on the callee (mips32 or mips16 mode function), the register will be where it expects it to be. Reed>>> 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. >>> >>> -Hal >> I should probably qualify this with "1000 times messier for me" :) >> >> In this case the whole problem fit neatly in a simple IR level module pass. >> >> I had to create an alternate calling convention for one part but otherwise >> this IR >> pass made an otherwise very messy problem easy to implement. >> >> Reed >> >> >>>> There are other stubs to be created for other parts of the mips32 >>>> port. >>>> >>>> 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 >>>> printer >>>> 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() && >>>> MAI->getInlineAsmStart()[0]) >>>> OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ >>>> MAI->getInlineAsmStart()); >>>> >>>> So a simple method in AsmPrinter would be the easiest for people to >>>> use. >>>> >>>> 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 >>>> not >>>> of the compiler emitting inline assembly. >>>> >>>> >>>> Reed >>>> >>>> >>>> >>>>>> 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 >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On 05/06/2013 04:23 PM, Eric Christopher wrote:> On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> wrote: >> Hi Hal, >> >> >> 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'm pretty sure you're the only one who thinks this. What's so > complicated about doing this either at selection dag or MI lowering > time? > > -ericAn earlier part of this I actually did do with selection DAG and it was messy and the code was much less easy to understand than this Module IR pass is. r173320 I intend to move most of this code into the new pass at a later time. It will make it possible to understand the whole scheme in one place. Much of the code needs to access the IR anyway, even though it finds it starting with the 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. >>> >>> -Hal >> I should probably qualify this with "1000 times messier for me" :) >> >> In this case the whole problem fit neatly in a simple IR level module pass. >> >> I had to create an alternate calling convention for one part but otherwise >> this IR >> pass made an otherwise very messy problem easy to implement. >> >> Reed >> >> >>>> There are other stubs to be created for other parts of the mips32 >>>> port. >>>> >>>> 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 >>>> printer >>>> 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() && >>>> MAI->getInlineAsmStart()[0]) >>>> OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+ >>>> MAI->getInlineAsmStart()); >>>> >>>> So a simple method in AsmPrinter would be the easiest for people to >>>> use. >>>> >>>> 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 >>>> not >>>> of the compiler emitting inline assembly. >>>> >>>> >>>> Reed >>>> >>>> >>>> >>>>>> 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 >>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >>>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev