[PATCH] Set basic block start as microMIPS

Jack Carter Jack.Carter at imgtec.com
Thu Jan 9 10:52:10 PST 2014


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. 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.

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.

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.

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

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

The bottom line is that a blanket rule is leaving us with blind spots testing wise. 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.

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

On 20 December 2013 17:23, Jack Carter <Jack.Carter at imgtec.com> wrote:
> Zoran,
>
> Patches, compiles, tests and code looks ok.
>
> You may get pushback for not having a .s testcase.
> The intragrated assembler is only tested for .s output. For the ELF object
> testing one is suppose to use llvm-mc.
>
> I know it doesn't make sense in this case, but it is what it is.

It makes perfect sense. Why would there be an object only code path in
here? If the patch changes generated assembly it should FileCheck the
assembly. If the patch adds features to the assembler it should use
llvm-mc.

Cheers,
Rafael





More information about the llvm-commits mailing list