16 yrs old - she/her
tldr: i work in rust and ts, i love mv-calculus, react, reverse-engineering and algorithms
experienced heaviest in rust and typescript but i can also work in objective c, c#, python, etc
i've messed a lot with the react internals and i understand how the rendering process works to a good extent. i've worked on tools which require hoisting react to hook its methods and as such i understand how the tree works, how hooks work internally, how to optimize the code, how the react dispatcher and virtual dom works, how react-dom renders the react tree, etc.
my main source of knowledge is reverse engineering- specifically discord react native client modifications
i also have an ongoing project for my own c-style language called Elle that i wrote in Rust which uses the QBE compiler backend
if you want more info, check out my github i guess
From Rosie to ~mpu/qbe
Yeah, I suppose. From what I read, in LLVM when you do `alloca` you explicitly request a stack slot, so surely allocN in QBE should act the same way?
From Rosie to ~mpu/qbe
> But it is used: it gets returned. It is? but don't both functions use `mov w0, #0` ie returning 0?
From Rosie to ~mpu/qbe
I think this behavior is actually QBE just optimizing out unused stack allocations completely, staring at it for a while. I do wish there was a way to prevent this.
From Rosie to ~mpu/qbe
Yeah, it's kinda weird. This is the IR: ```qbe function w $foo() { @start %a.addr =l alloc4 8 %tmp =l copy 0 storel %tmp, %a.addr ret 0 } ``` ```s
From Rosie to ~mpu/qbe
I seem to have found the issue -- QBE seems to optimize variables deemed small enough into general purpose registers instead of pushing them to the stack: ```s mov w1, #24 bl _GCAllocator.alloc adrp x0, ___internal.elle.__env__@page add x0, x0, ___internal.elle.__env__@pageoff ldr x0, [x0] ldr x0, [x0] ``` vs. what it should be (for the garbage collector to find it as a root)
From Rosie to ~mpu/qbe
That was my original approach because I can do it from the language itself so it could just be an stdlib function, but it's not as reliable as I'd like. It sometimes fails to find 1/2 pointers (from the example outlined above) while __builtin_frame_address always finds both, which is strange because I'd expect the portable solution to also work reliably.
From Rosie to ~mpu/qbe
Yep, this works: ```c void *__internal_get_frame_address() { return __builtin_frame_address(1); } ``` At compile time, I compile this and link with the object. I'm not sure why I didn't think of this lol, thank you.
From Rosie to ~mpu/qbe
>You can rely on your C compiler and write a stub that wraps __builtin_frame_address(1). This stub is then easily called from qbe il. Sorry I only just saw this. That might actually be a simpler way to do that, thank you I think that should work.
From Rosie to ~mpu/qbe
Update: I wrote a somewhat automatic runtime thing which automatically compiles and links a tiny amount of assembly for the architecture that the compiler was compiled on (only aarch64 and x86_64 are supported for now) ```s .text .balign 4 .global ___internal_get_frame_address ___internal_get_frame_address: mov x0, x29 ret ``` ```s
From Rosie to ~mpu/qbe
Consider the following C function: ```c #include <stdio.h> int main() { printf("%p\n", __builtin_frame_address(0)); return 0; } ``` which prints the stack frame pointer of the current function (using the GCC __builtin_frame_address).