[LLVMdev] #APP/#NOAPP

[reed kotler]

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