[PATCH] Support for microMIPS relocations 1/3

[Rich Fuhler]

> From: Rafael Espíndola [rafael.espindola at gmail.com]
> Sent: Tuesday, October 01, 2013 11:57 AM
> To: Jack Carter
> Cc: Zoran Jovanovic; llvm-commits at cs.uiuc.edu
> Subject: Re: [PATCH] Support for microMIPS relocations 1/3
>
> On 1 October 2013 14:50, Jack Carter <Jack.Carter at imgtec.com> wrote:
>> There are 2 tools using the same code. Can they both use it correctly? Are the calls through both AsmPrinter and AsmParser going to get a correct result? The long term customer use will be to use direct object emission. To not test it directly is ill advised.
>>
>> The only way to be sure is to test the output both of the products, and to test them with independent tools.
>>
>> If this will block us from checking in the patch, I will relent for expediency sake, but not testing the output of both tools is basically wrong.
>
> That is *not* the design goal of MC or more generally of the llvm
> tests. Driver tests check the -cc1 command line, clang tests check the
> emitted llvm, etc.
>
> The exceptions are few. In the case of MC, llc + llvm-mc are designed
> to produce the same output as direct emission. The one exception that
> I know of is relaxation of multiple instructions that print the same
> in a .s.
>
> In the past having direct object emission tests was the most annoying
> and brittle part of llvm by far. Now that we have a mature MC
> infrastructure we are in a position where we can require that any
> direct object emission feature is tested with llvm-mc and any codegen
> feature is tested with llc printing assembly. I think we should do so.
>
> Cheers,
> Rafael

Hi Rafael, we haven't had the pleasure of talking before. I'm the technical lead of Imagination's LLVM and GCC compilers for MIPS and IMG's META processors. Worked a lot with Bruno in the "early" days of MIPS LLVM: spec'ing out and hiring the compiler team and getting several key licensees on board. Bruno is also the person who convinced me to switch over to the MC layer - right decision, a lot of work.

Basically, the new paradigm of having the assembler first (or assembly first that's assembled by another assembler) is understandable. For a lot of reasons over the last couple of years, Android (MC-JIT) and Chrome/PNaCL (no .s), we've had to focus on direct object emitters first - before assembly/assembler.

We've been working like mad to get the assembler caught up, but let's face it, MIPS ISA conventions over 20 years has varied and in some cases is inconsistent. We've had to add functionality to tablegen, patch common code in MC layer, rewrite our TDs to accommodate changes, and add a tremendous amount of support for MIPS32, MIPS64, microMIPS, and (upcoming) MIPS16e. We also have the extensions: FPU, DSP, and MSA (SIMD) - all with their own issues and all in process now. We will need MSA (SIMD) with direct-object emitters before .s files. I'm not whining, just giving a little concise (hopefully) history.  

One of the problem areas in MIPS assembly code are attribute pseudos that change state in the ELF header - and even change encoders. MIPS allows microMIPS and MIPS32r2 to be in the same object file - same for MIPS16e and MIPS32r2. The toggling of the encoders can be done on a per function basis within the module. We've dealt with this encoder changing in LLC, I think the assembler might need some work yet. Additionally, we have have arcane attributes, like "abicalls", that set flags in the header.

These flags are aggregated through assembling. In the DOE, the code that closes the object file writes out these flags (as I understand it). The assembler doesn't use the same path when closing the object file and the flags aren't written. Consequently, we're stuck. We can't get the flags into the .o to do the comparison we need for the tests. The patch for this has gone through several iterations and I think we've been back and forth with you and/or Jim for 4 months? Without this patch, we're at a standstill on the assembler for microMIPS, MIPS64 PIC, and (soon) MIPS16.

So we're sort of at a chicken and egg impasse. We cannot move forward in the assembler, and without the LLC testing, we can't move forward with microMIPS (and I've got a commitment for microMIPS with DOE due soon).

If we can get the header flags issue resolved, I can shift some resources around to get the assembler up to snuff so that we can provide test cases that use llvm-mc. But right now, we're dead in the water and there are a few ruffled feathers. Can we get some help with the stuck patch? (watch, as soon as I send this, the patch will be committed...)

thanks for reading, pardon any typos or inaccuracies...

Rich Fuhler
Principal Software Design Engineer, MIPS processor IP
Imagination Technologies
t: +1 408 530 5000
m: +1 408 515 7038
www.imgtec.com