[LLVMdev] making emitInlineAsm protected

[reed kotler]

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?
>
> -eric
I'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