[LLVMdev] Advice on architecture research project?

David A. Greene greened at obbligato.org
Thu Jun 9 17:09:01 PDT 2011


Benjamin Ylvisaker <benjaminy at alumni.cmu.edu> writes:

> I am interested in working on a little architecture project that  
> involves modifying an ISA in some non-trivial ways and seeing what  
> impact it has on instruction frequencies (and other such metrics).   
> Clearly I'll need to hack on a compiler backend, and I thought that  
> LLVM might be a good choice since among mature compiler  
> infrastructures it's fairly young and presumably relatively clean.  I  
> will also need to choose an ISA and a functional simulator (which I  
> will also need to hack) for the evaluation.  I'm not particularly  
> interested in micro-architecture level accuracy, so I'd rather avoid  
> that complexity if possible.  I think I'd rather start with an ISA  
> more in the RISC family.
>
> Does anyone have a suggestion about ISAs for which there is a good  
> LLVM backend and an open source/customizable functional simulator?

I agree that ARM is a good choice.  MIPS is less well supported in LLVM,
I think.

But don't count out venerable X86.  There are simulators available for
it, both open- and closed-source.

Note that things like instruction frequencies are highly ISA-dependent.
If possible, it is best to evaluate your ideas on more than one target,
just to see what the effects are.  What other sorts of things do you
want to study?

If, long-term, you are planning to do serious studies of performance
impacts, I very highly recommend you not rely on simulators if at all
possible.  I have never met a simulator ("cycle-accurate" or not) that
even comes close to giving reasonable performance predictions.

I admit this is rather difficult to do if you are exposing some new
hardware magic to the ISA.  In cases like this I have long believed that
availability of compiler and simulator source code should be a bare
minimum prerequisite for publication.  Unfortunately, I seem to be in a
rather small minority.

                            -Dave



More information about the llvm-dev mailing list