[LLVMdev] #APP/#NOAPP

[Eric Christopher]

That code looks a little odd but not too awful. I still don't
understand what's so wrong/complicated about this. You seem to be of
the opinion that injecting asm into a stream ala gcc is a good idea in
clang, it really isn't.

-eric

On Mon, May 6, 2013 at 5:45 PM, reed kotler <rkotler at mips.com> wrote:
> 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
>
> An 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
>
>
>