[PATCH] Set basic block start as microMIPS

[Jack Carter]

Ok, with the latest changes of the backend using the MC interface I see it.

I'm assuming you want the "hack" routine to stay in place for default and commandline eheader checking or having both AsmPrinter and AsmParser using the same interface and just having llvm-mc produce the test case good enough?

Jack
________________________________________
From: Rafael Espíndola [rafael.espindola at gmail.com]
Sent: Thursday, January 09, 2014 12:14 PM
To: Jack Carter
Cc: Zoran Jovanovic; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Set basic block start as microMIPS

On 9 January 2014 13:52, Jack Carter <Jack.Carter at imgtec.com> wrote:
> Once again, it does make a difference.
>
> The integrated assembler and the standalone assembler use common methods, but they invoke those common methods independently through separate mechanisms.

If they do that, that is a bug and must be fixed. The code generator
uses *exactly* the same interface for text and object files. So does
the assembler (llvm-mc).

> I am calling the same method for output from different parts of the compiler, but only testing one of them. Doesn't make sense if you are intending this to be a product you will ship and customers will actually use.

You can test that. One step at at time. You check the codegen side by
running FileCheck on the assembly. You then use llvm-mc to read the
assembly and drive exactly the same interface and produce an object
file. The *only* reasonable case for *ever* having a test run llc with
-filetype=obj are instruction relaxations that are skipped in direct
object emission.

> When You and I were discussing this issue with Chris L. at the conference, it was pointed out that the reason for not using the integrated assembler object output was because of variations in code and register usages. And I agreed that that is a good point.

No, it was not. You need an assembler that can read your output if you
want your target to do direct object emission. Forcing the rest of the
community to take a target that must be tested with "llc
-flitetype=obj" is an unacceptable burden.

> That does not make a reasonable point for uses where instruction/data sizes are checked as well as specific registers. For instance. Checking for the generation of a specific relocation type, symbol type, ELF header flags.

That uses the *same* code path and *must* be tested with llvm-mc. The
codegen will print something like @PLT, llvm-mc will parse that, call
the very same method (now in the object streamer) and you can then
check the relocation in the object files.

> These should all be tested for both the integrated and standalone assembler.

They should *never* be tested via "llc -filetype=obj". Always via llc + llvm-mc.

> Exception handling data should have a pretty printer so I can be checked from both assemblers.

You are using a wrong terminology. There is one assembler in llvm.
Yes, we should (and have some) dumpers for exception data. If the
assembly is hard to check, it is perfectly fine to write the test with
; RUN: llc %s -o -  | llvm-mc -filetype=obj | llvm-readobj

what is *never* OK is to add a test with "llc -filetype=obj".

> The bottom line is that a blanket rule is leaving us with blind spots testing wise.

Show them. If there is ever code with different behavior for asm and
object, that is a bug (as there were plenty in the mips backend) and
should be fixed. If the behavior is the same, you can  test it from
the .s.

> The restrictions on what .ll direct object tests can be tested through pretty printers should be spelled out with specifics and intelligence. State what elements are not to be tested from a specific output mode and specifically and technically why.
>
> The current rule of "just don't do it" is way too restrictive and leaves big wholes in our regression testing. Some times it makes sense to ban the usage, other times not.

It is not. Point to the code where a code path is used only for asm or
only for obj. In every case you argued that before it was a broken
design in mips backend.

The MC layer has to be the simplest design pattern ever. You have one
method per assembly directive. The asm streamer prints code. The
object streamer with the very same calls prints objects. Both llvm-mc
and llc use the *very* same interface in *exactly* the same way for
asm and object (with the exception of relaxations and bugs).

Now,  we can test if llc is using the interface correctly by checking
if the assembly that is being printed is what we expected. We can then
test if the the objecstreamer works correctly by  with assembly input
that will drive the interface in the same way codegen did. We this we
test both ends of the interface.

Allowing tests to use llc -filetype=obj is an extremely slippery slop.
Take it and you are doomed to get a compiler that can produce an
object file with no corresponding assembly file and is extremely hard
to debug. At different points that was the case of ARM, PPC-ELF and
then Mips. We should not go back there.

Cheers,
Rafael