[LLVMdev] Multimedia IO instructions & partial backend implementations for simple CPUs

[Sean Silva]

On Sat, Nov 2, 2013 at 2:48 PM, Rob Stewart <robstewart57 at gmail.com> wrote:

> Hi, I'm getting started with LLVM, with the intention of writing a DSL
> that compiles to LLVM IR, to target a new CPU instruction set. I have
> two questions:
>
> 1. Multimedia IO in LLVM
>
> In the paper "The LLVM Instruction Set and Compilation Strategy" [1],
> there is talk about a possible multimedia instruction set in a future
> LLVM release:
>
> "Note that LLVM is a virtual instruction set: it does not define
> runtime and operating system functions such as I/O, memory management
> (in particular, garbage collection), signals, and many others. Some
> issues that do belong in the instruction set and may be added in the
> future include support for multimedia instructions (e.g., packed
> operations),
> predicated instructions, and explicit parallelism."
>

We have vectors. No predicated instructions in the LLVM IR (only in the MI
layer). I'm not sure what you mean by "explicit parallelism" (do you mean
something like Cilk?) but I don't think LLVM supports that (those things
usually have a nontrivial runtime component).


>
> My question is a very basic one: how do I use LLVM IR code to do file
> IO? As a simple example, take a file with 3 tab-separated integers.
> How would I read this file in to an LLVM vector <3 x i32> ? Now take a
> more complicated example: decoding a file to an LLVM vector
> representation. To use the multimedia instruction set described above
> (though I guess not implemented yet), how do I: A) read a greyscale
> 3x3 pixel image file, B) translate this to an LLVM vector <9 x i8> ?
>

LLVM doesn't provide a runtime or "VM". You basically do these things the
same way that you do them in C. Yes, this unfortunately requires knowing
your target platform's system libraries and how to link to them and such;
LLVM doesn't paper over this.


>
>
> 2. Implementing an LLVM backend subset.
>
> I have not yet delved deeply in to the requirements of implementing
> LLVM backends to target new hardware instruction sets. Given a
> constrained hardware implementation, is it acceptable to implement a
> backend subset, and throwing "Not Supported" exceptions where ever
> appropriate. To give a concrete example, take a simple CPU
> architecture that does not support floating point arithmetic, but does
> support simple integer arithmetic. If my LLVM frontend produces only
> i32 values, then `llc -march=my_new_arch` doesn't complain. If,
> however, my frontend produces float values, then `llc
> -marc=my_new_arch` would complain with the "Type 'float' Not Supported
> by architecture my_new_arch".
>
> Is this the philosophy of LLVM backend implementation? Must the new
> target architecture support all LLVM instructions, or am I able to
> develop an LLVM backend for an architecture that lacks features like
> floating point arithmetic? Any related resources would be appreciated.
>

If you don't want to merge this with trunk, then you can do whatever you
want; typically when starting out you will only implement a subset of
instructions (you can't implement them all simultaneously, now can you?).
The state of backend documentation is pretty dire. I brain dumped basically
all the backend docs I could think of in <
http://thread.gmane.org/gmane.comp.compilers.llvm.devel/65898>. That thread
also has some other good pointers for a person interested in writing a
backend.

Getting a backend intro trunk generally speaking is a large long-term
commitment. I'm not sure what the exact requirements are for getting a
backend into trunk (I don't think anybody really does at a deep level,
other than "some critical subset of experienced LLVM developers think it
looks good enough to be committed"), but the biggest hurdle (generally)
with getting a backend into LLVM trunk is that it requires a demonstrated
ability to work with the community and a clear investment in maintaining
the backend from now into the foreseeable future (to put it bluntly, this
generally will mean at least 1 or 2 people with a paycheck tied to
maintaining the backend and contributing to the community, and these being
people that have a history of submitting good patches and that are familiar
with the community expectations). (The reason for these requirements is
purely experience with other backends, which have been a maintainability
nightmare without active developers responsible for maintaining them and
compensating for the increase in general codebase complexity (e.g. each new
backend makes refactoring the target-independent backend parts more
difficult)).

-- Sean Silva


>
> [1] - http://goo.gl/HA5AXU
>
> --
> Rob
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131103/8538b99f/attachment.html>