Parallella Community

I just thought I'd let you know that I've been working on a epiphany llvm backend for the past month or so, it's not quite ready yet, but I'll release it as soon as it is.
I did not plan to announce anything before releasing it, but with talk about a llvm backend as a gsoc project popping up suggested that it might be a good idea to mention it now because duplicating that work would probably be a waste of time.

If your up for it I'm interested in collaborating.
I have been doing research trying to figure out how to get started.

I was thinking about this myself, so this is good news! I'd be very willing to help out, I've been working on a different backend for my phd and would love to be able to use the epiphany instead. Any repo?

I know nothing about this compiler backend but I have been writing quite a bit of Epiphany assembler recently (mostly integer stuff) If you want to swap ideas for code sequences etc, feel free to get in touch.

Keeping the floating point system occupied with work is quite a challenge as there are noticeable pipeline delays. Ideally you need to be working on two, three or even four different calculations at once, interleaving them. In hand crafted assembler a bit of loop unrolling and interleaving would probably pay dividends (there are lots of registers to make use of).

I also wondered if it would be worthwhile where speed is more important than space to inline floating point functions - that gives more scope for interleaving with other stuff. Also avoids the call return overhead (8 cycles excluding any stack frame formation) Perhaps that is a more advanced topic, need to get basics going first.

Tim

One of the nice things with llvm is that you can optimize separately from the code generation.

The first stage of the compilation is translating the program code Into the llvm Intermediate Representation (IR). (front end)
IR is a well defined RISC Assembly like language.
The second stage is running the IR through several optimization passes, this could be as simple as rearranging the instructions to take advantage of the pipeline.

the final stage is the optimized IR is feed into the code generator (also called the back-end), this is where the program becomes executable.

because of the disconnected nature of the components, it is entirely possible to have a team working on the code generator, and another working on optimization.

It is also relatively simple to describe target pipeline latencies, and these latencies can be used by a number of, already implemented, schedulers. But as mentioned before, the basic blocks need to have enough instructions in them in the first place - but there is already a loop unroller pass. And I doubt that with computationally heavy code such as OpenCL, which has a lot of explicit data parallelism, there would be a lack of fp operations.

While I do appreciate the help offers I'm currently happy doing everything myself - after all I'm doing it for fun in my spare time, not because I get paid for it. There will be plenty of opportunity for other people to contribute as soon as I put it on github.
I do not have a board yet, and while it sure would be nice having one and being able to attach some sdr stuff to it it's not really necessary right now, after all building a backend does not depend on trial and error.
As far as the current progress is concerned, I do have an ASM writer (we already have binutils, so there is no need to mess with outputting binaries for now) and the generated code is pretty much able to match the output of gcc with "-mcmove -mno-soft-cmpsf -mshort-calls -mfp-mode=round-nearest -fomit-frame-pointer -ffast-math -O3", this combination of flags is my current target, since i'll use the backend for some SDR stuff as soon as the Parallela arrives.

Hoernchen : do you have a code repo for this LLVM work anywhere? A github perhaps? I'd be very interested in helping out or at least testing it.

If you just want to use the backend come back later when it's finished, at the current stage it's only useful if you plan to work on it.

The good stuff lives here: https://github.com/Hoernchen
Building is pretty much straightforward, clone llvm, checkout epiphany, cd llvm/tools, clone clang, checkout epiphany, cd llvm/lib/Target, clone Epiphany
You need to use cmake, the necessary settings are -DLLVM_TARGETS_TO_BUILD="AArch64;Epiphany" -DCMAKE_BUILD_TYPE=Debug - the build needs a few gigabytes of space, so plan ahead.

I chose to base the backend on AArch64 because it is the newest backend that is "ARM-like", and the actual ARM backend is not really a good example for anything because it supports thumbv1/2, vfpv2/3, neon, and pretty much everything else there is so the code is a bit of a mess. This is why most of the code, including the comments, looks like aarch64 backend code - there is no reason to reinvent the wheel, most problems you're facing when working on a backend are far from unique, so looking at all the other existing backends makes sense.
My primary goal was to match "epiphany-elf-gcc -S -c -o - -mcmove -mno-soft-cmpsf -mshort-calls -mfp-mode=round-nearest -fomit-frame-pointer -ffast-math -O3" because I'm mostly interested in using the epiphany for stuff it is good at, which means dsp stuff involving floats. At the moment I'm still using the aarch64 clang frontend, because it "just works", although in the long run this will obviously require some work.

Using the backend works like this: clang -target aarch64--eabi -emit-llvm foobla.c -c -O3 -ffast-math -fomit-frame-pointer -o - -S -ffp-contract=fast | llc -march=epiphany

So, let's sum up what it does have:
* asm printer that is not immediately compatible with the epiphany binutils (printing of floating point constants, double reg names, ..) because this is my "debug output"
* FMA/FMSUB support
* a pass that removes unnecessary compares
* a pass that tries to combine loads and stores to double loads and stores if the alignment matches, mostly useful for stuff involving the complex floats, manually providing the alignment using __builtin_assume_aligned is necessary for this. This can be enabled with -double-ls. Code to try, provided by tnt: http://pastebin.com/A6xp01R6 and http://pastebin.com/K0RNCgzg

..and what it doesn't have:
* elf writer
* instruction encoding, because there is no elf writer
* support for the secondary integer instructions
* switching of rounding modes for float/fix
* postmodify loads and stores, this might need a pass after the double l/s combine pass
* software float compares, ieee-754 style, for proper inf/nan handling
* support for variadic functions
* a call convention that is rock solid
* -O0 breaks stuff
* target specific scheduling
* R63, because I abuse that reg as destination for compares and for some other stuff
* tail call optimizations (not particularly important)
* pretty code
* probably something else i forgot to mention

In short, expect it to break, fix it, rinse and repeat.