making emitInlineAsm protected

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

Uhhhh...

-eric

Uhhhh...

Is that a yes?

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

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 .

You mean Printer? There is no such a thing as inline asm in a .s file.

Are there any objections to doing this?

Probably. EmitInilneAsm is the only case I know that has a reasonable
use of hasRawTextSupport in order for it to work on targets without an
asm parser. Exposing it exposes a way for targets avoid the MC layer.

Cheers,
Rafael

So how do I create stubs?

I have specific function stubs that I want to create.

There is no direct object emitter for mips16 at this time.

Reed

So how do I create stubs?

I have specific function stubs that I want to create.

There is no direct object emitter for mips16 at this time.

Print it like any other instruction?

Cheers,
Rafael

Where am I supposed to be doing that?

I have to create new functions.

Reed

Why not just do this in asmprinter?

It's very straightforward there.

I've already written the code to this in asm printer.

Where is it written that you are not supposed to do this?

You should make the data structures private in that case.

I'm using all public interfaces.

Reed

The other problem here is that I have to emit mips32 code for these stubs and I'm in mips16 mode while I'm compiling
the function that needs the stub.

It's a different instruction set.

I'd like to just check my code in and then you can look at it in it's totality and see if you have
a better solution .

Reed

So how do I create stubs?

I have specific function stubs that I want to create.

There is no direct object emitter for mips16 at this time.

Print it like any other instruction?

Cheers,
Rafael

I'd like to just check my code in and then you can look at it in it's
totality and see if you have
a better solution .

No. Please don't do this. You already had two people say "I don't
think this is the right solution."

-eric

I'd like to just check my code in and then you can look at it in it's
totality and see if you have
a better solution .

No!

If it is the compiler creating instructions, it is not inline
assembly. If you need to print mips16 and mips32 and they are two
independent instruction sets, my guess is that you need to figure out
how to swap between two AsmPrinters.

Cheers,
Rafael

We do switch them already.

We create different functions for the stubs and assign them the mips32 attribute.

Then they get assembled.

The need for these particular stubs cannot be recognized until isel lowering.

Why do I need to make a complex mechanism here when all I need to do is emit some
some inline assembly code at the end of asm printer?

What purpose will this serve?

Reed

Because we're not an assembly emitting compiler. We're an object file
emitting compiler and it's breaking abstractions. The correct way to
do the work here is to emit the functions and lower them
appropriately.

-eric

So explain to me how this mechanism would work.

As I'm processing a single mips16 function, I realize that I need to create one or more mips32 helper functions.

I'm in a function pass. So I'm not supposed to be creating new functions, as far as I understand.

Also, I can't know which mips32 stub functions to create until I have processed all functions because otherwise I might create duplicates.

So how would you do this within the existing LLVM pass structure?

Reed

So explain to me how this mechanism would work.

As I'm processing a single mips16 function, I realize that I need to create
one or more mips32 helper functions.

I'm in a function pass. So I'm not supposed to be creating new functions, as
far as I understand.

Also, I can't know which mips32 stub functions to create until I have
processed all functions because otherwise I might create duplicates.

So how would you do this within the existing LLVM pass structure?

A module pass that iterates oven the functions should do it.

Cheers,
Rafael