Live data from Hacker News

LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

github.com

31–40 of 54 posts

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#31
post #29

Earlier quoted context omitted.

"A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :( Have you considered this is a deliberate decision, with a goal of having most targets in-tree? :)

Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.

It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#32
post #31
post #29

Earlier quoted context omitted.

Why is this beneficial? It means you need to change several repositories to add one target triple. This may be a win in terms of in-tree stability, but it reduces accessibility to everyone else.

It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.

Does Apple have some proprietary backends? I guess they have the resources to maintain such.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#33

What can you do with this?

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4 (I explained why in my blog). I haven't had the time to work on my firmware recently due to IRL events so I decided to publish the compiler. Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boar…

Great work. Very interested to see what you have going on the firmware side.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#34
post #7

You can run C code on GPUs? I don't know anything about GPUs, but I thought they had a completely different programming model that requires different programming languages and paradigms.

Yes and no. You can definitely run arbitrary C code on AMD's GCN ISA if you're so inclined (and I expect every other modern GPU, but I know less about those...). There are all the usual assembly instructions, there are pointers, you can implement a stack, and so on. That doesn't mean that arbitrary C code will run fast :)

To fully use the computational power of the GPU, you have to make use of its parallelism. That means dealing with the fact that you can have hundreds or thousands of "waves" (things with a register file and a program counter) in flight simultaneously, and each "wave" corresponds to many (in AMD's case, 64) threads in the conventional sense.

It is the last part that makes the biggest difference compared to regular CPUs, because it changes how you have to think about control flow. If/else-statements must be compiled in such a way that the wave goes through both branches if the threads in the wave branch differently (if all threads branch the same way, you can of course skip the other branch).

The first part makes a big difference as well, of course. GPUs care far less about single-threaded performance, so there is no out-of-order or speculative execution, and the memory latency is high. When a wave has to wait, the latency is made up for by scheduling another wave instead. That is, there is a high level of what is called "hyper-threading" on the CPU.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#35
post #31

Earlier quoted context omitted.

It is beneficial in that it discourages proprietary backends to LLVM which are not contributed back to LLVM. It is the same benefit GCC enjoys by using GPL.

Does Apple have some proprietary backends? I guess they have the resources to maintain such.

Yes, they definitely do.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#36

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-…

It depends what you mean by "plugin": targets are configured at compile time. I don't think you can build LLVM and then dynamically load a backend as plugin.

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#38
post #36

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-…

It depends what you mean by "plugin": targets are configured at compile time. I don't think you can build LLVM and then dynamically load a backend as plugin.

You can load targets as plugins in llc :)

You cannot load targets as plugins in clang :(

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#39

It bugs me that LLVM targets are not properly 'plug in'. LLVM backends can be in a plugin, but you have to tell the frontend which target to use (so it can use the correct data-layout etc). Its the frontends that don't support plug-in targets. Clang, for example, hardcodes the supported targets. A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-…

"A combination of using enums as a 'target triple' and lack of dynamic target registration conspire against easy-to-use out-of-tree targets :( Have you considered this is a deliberate decision, with a goal of having most targets in-tree? :)

Which makes developing a large backend a lot of pointless busywork with patchsets touching parts of the codebase that really ought not need touching at all :(

(I'm someone who was stuck on 3.6 for ages because of the pain of keeping up with the trunk)

Re: LLVM Backend for the VideoCore4, Raspberry Pi 2 VPU

#40

Earlier quoted context omitted.

To elaborate, I made this to develop an open source VPU side bootloader for Raspberry Pi because I was unhappy with the state of other C compilers targeting VC4 (I explained why in my blog). I haven't had the time to work on my firmware recently due to IRL events so I decided to publish the compiler. Not publishing any of the firmware work yet since it can't boot ARM yet (but SDRAM init reliably works across all boar…

Thanks for making this work! I'd given up on the LLVM backend completely due to showstopping issues I couldn't resolve, and had assumed it had vanished into the aether. Glad to know you found it useful! Regarding the boot loader, have you seen my piface boot loader? http://cowlark.com/piface/ It sounds like what you have is way more sophisticated, as I never got SDRAM init working properly, but you never know --- the…

Yeah I looked at it, my firmware mostly just aims at bringing up enough stuff to be able to boot ARM, which is essentially just:

  - Setting up exception vectors and enabling exceptions
  - Reclocking VPU from PLLC
  - UART initialization
  - SDRAM initialization
  - Copying an ARM blinker stub to 0x0
  - ARM power domain initialization
  - PLLB initialization
  - Enabling passthrough mapping for ARM
  - ARM AXI interface initilaization
I'm still trying to figure out what I'm missing in order to get it to work but I suspect it's related to not properly setting up the ARM PLL. I was going to port the RPi clock management driver from Linux but I don't have the time at the moment.

As far as the compiler goes, I think it works reasonably well, though I only tested it by compiling my own code with it, there may be things that cause it to error out (anything that involves the frame pointer like VLAs/some C++ features). Also code quality is not ideal since it still doesn't make use of conditional instructions (aside from conditional branches) and doesn't implement AnalyzeBranch to eliminate redundant branches.

I started cleaning up TableGen to turn multi-instruction asm prints into glue DAG in SelDAGtoDAG but I still have to do it for like 4 instructions, which is pretty much a requirement to have MC code emission.

Post reply on HN