JuliaGPU / JuliaGPU/GPUCompiler.jl

Pointers from the host in the cross-compiled LLVM IR

Open
#759 6 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Julia
Stars
187
Forks
69
Avg merge
1d 12h
Merged PRs (30d)
28

Description

I am using GPUCompiler to cross-compile julia code for a RISC-V based microcontroller (ESP32 c3). The entry-points using the Arduino API are a setup() (for initialization) and a loop() function (to be run repeatedly). Here is an example in C++:

https://github.com/arduino/arduino-examples/blob/main/examples/01.Basics/Blink/Blink.ino

I would like to emulate this kind of API in julia.
Both functions do not have any arguments, therefore all shared information must be with global variables.

For all global variables, GPUCompiler uses the memory address of the host, for example:

module blinking_leds
using ESP32RISCVCompiler.Arduino

const counter = Ref{Int32}()

function setup()
    counter[] = 0
end

function loop()
end
end

This gets compiled into:

define i32 @_Z5setupv() local_unnamed_addr {                                                                                                                          
top:                                                                                                                                                                  
  store i32 0, ptr inttoptr (i32 -779740248 to ptr), align 4, !tbaa !2, !alias.scope !7, !noalias !10                                                                 
  ret i32 0                                                                                                                                                           
}

where -779740248 corresponds to Int32(pointer_from_objref(blinking_leds.counter)) on the host.
My current approach is to get a list of all module-global variables (using names(julia_module,all=true)), traverse the LLVM IR to remove all pointers matching module-global variables and to replace them by global variables declared in LLVM IR (https://codeberg.org/Alexander-Barth/ESP32RISCVCompiler/src/branch/main/src/global_references.jl#L103-L120).

Here is some initial discussion about this:
https://discourse.julialang.org/t/compiling-julia-code-for-a-risc-v-esp32-microcontroller/135108/3

I am wondering if there is a better way to do this?

A more complicated issue is the handling of string literals where I have also the problem that pointers from the host are present in the compiled binary. Unfortunately they are more difficult to handle as in the resulting LLVM IR there is no information left that this pointer represents a string:

function setup()
    a = "abc"
end

becomes:

define nonnull ptr @_Z5setupv() local_unnamed_addr {
top:
  ret ptr inttoptr (i32 -426048800 to ptr)
}

Maybe is it possible to use some LLVM metadata or to transform the code at a different level of the compilation pipeline?

I am well aware that an esp32 device is not exactly a GPU :-) Let me know if this should be rather a discussion post on discourse rather than an issue here.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the emitted LLVM IR examples and the referenced global_references.jl code around lines 103-120, then trace the relevant GPUCompiler compilation stages. Compare how module globals and string literals appear in the IR; done would require an agreed, maintainable approach or guidance for handling these host pointers during cross-compilation.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
compilers, embedded-iot
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.