Adding Intrinsics for custom processor (frotend problem)

Project Infrastructure LLVM Dev List Archives
1

Chris Lattner wrote:

As others have mentioned, hacking the front-end isn't that hard. In any case though, please be aware that a precompiled binary for a non- MIPS target won't produce correct code if you are (for example) using an x86 front-end and forcing llc to generate mips code with llc - march=mips. The front-end does type layout and knows very ABI things that have to be right for mips.

-Chris

Thanks for your reply Chris.
I would still like to use the 'standard' precompiled binary for llvm-gcc front end unless its really impossible. Actually I thought that the whole idea of LLVM was to have an abstract middle level so that front end does not have to know 'very ABI things' :slight_smile: . To make things clear, I am using the frontend only with -emit-llvm flag, and then run my llc, but I guess this is obvious, so I was wondering if you can expound on what kind of problems I may encounter.

Actually, the strategy of using only the precompiled binary front end worked for us satisfactorily in our previous processor iteration, a very non-standard stack machine architecture so I doubt we would have an insurmountable problem doing the same now, with the new little endian MIPS like architecture.

To put things in perspective: we only require a subset of "C" to be supported by the compiler. Our processor is in fact a low level DSP like sub-processor in the whole chip, which runs relatively small and simple programs (it has only 16K program memory after all), and all the existing code base is currently written by us in that subset. If unions/bitfields would not work , or passing structs by value, then fine, we'd have no problem officially not supporting this features. MIPS calling convention ABI, is also not relevant for us. We may use it if it works fine, but if not we might ditch it altogether for a simpler calling convention, and might even decide not to support a stack at all (Our current "C" subset does not allow recursion).

Anyways, as I noticed the MIPS backend, is not really finished and have some bugs still (I reported some to Bruno), but it is much easier work to have that "almost working" code as a starting point, than having to write our backend from scratch ...

2

Chris Lattner wrote:

As others have mentioned, hacking the front-end isn't that hard. In
any case though, please be aware that a precompiled binary for a non-
MIPS target won't produce correct code if you are (for example) using
an x86 front-end and forcing llc to generate mips code with llc -
march=mips. The front-end does type layout and knows very ABI things
that have to be right for mips.

-Chris

Thanks for your reply Chris.
I would still like to use the 'standard' precompiled binary for llvm-gcc
front end unless its really impossible.

If you want 100% correctness, it is.

Actually I thought that the
whole idea of LLVM was to have an abstract middle level so that front
end does not have to know 'very ABI things' :slight_smile: .

Yes it is. LLVM continues to keep getting better in that respect, but at the end of the day, LLVM is defined to be independent of source language and ABIs are typically defined in terms of C. There is a many to one mapping between C constructs and LLVM IR, so things that depending on the distinctions in C cannot currently be regurgitated by the code generator.

Actually, the strategy of using only the precompiled binary front end
worked for us satisfactorily in our previous processor iteration, a very
non-standard stack machine architecture so I doubt we would have an
insurmountable problem doing the same now, with the new little endian
MIPS like architecture.

If you don't care about the ABI (because you compile everything with llvm) and don't care about processor predefines (e.g. __i386__) then you can probably get a way with this.

-Chris