[LLVMdev] Does Mips resolve hazard in pre-ra-sched or post-ra-sched?

David Chisnall David.Chisnall at cl.cam.ac.uk
Wed Sep 25 01:04:45 PDT 2013


On 25 Sep 2013, at 04:48, Akira Hatanaka <ahatanak at gmail.com> wrote:

> I don't know for sure why stalls increase. In my experience, both pre-RA and post-RA improve performance when I run the compiled executables on a mips board. But as I said in my previous email, the model in MipsSchedule.td is just a generic one, so it's possible that it isn't generating efficient code for your target. 

At some point, it would be worth the parties interested in MIPS having a discussion about the correct way to support different variants.  We are going to be open sourcing our MIPS IV implementation soon[1], which is written in a high-level HDL (BlueSpec) and is designed for teaching and research, so we anticipate a lot of universities using it as a base for experimentation.  In the FreeBSD world, we also support a number of weird MIPS variants that use the CP2 instruction prefixes for interesting things.

In GCC, the traditional approach has been for each vendor to fork GCC and binutils, apply patches that add support for their architecture and break all of the others, and then fail to update them for any newer release, so you end up with the vendor's compiler (which is never updated, contains bugs, and misses support for newer language features) being the only one you can use when targeting a specific chip.

It would be great if we could structure the MIPS back end in such a way that it's easy to add processor variants that have very different interpretations of the CPx opcodes and instruction schedules, so that upstreaming vendor-specific modifications becomes easy (and out-of-tree implementations can be kept relatively isolated from changes upstream).  This is something I will have time to work on over the next few months, as we already have 3 derivatives of our implementation with different extensions and are likely to add a lot more over coming years.

David

[1] I have patches to add MIPS IV support almost ready to upstream.  Mostly it's a matter of changing the IsMIPS64 check to IsGPR64, and then adding some IsMIPS64 checks around a few instructions that are specific to MIPS64.



More information about the llvm-dev mailing list