jacklsw has quit [Read error: Connection reset by peer]
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #riscv
vagrantc has quit [Quit: leaving]
BootLayer_ has quit [Quit: Leaving]
brazuca has quit [Quit: Client closed]
___nick___ has quit [Ping timeout: 268 seconds]
Guest14 has joined #riscv
bob has quit [Remote host closed the connection]
geranim0 has quit [Remote host closed the connection]
Andre_H has quit [Ping timeout: 245 seconds]
KombuchaKip has joined #riscv
strlst has quit [Quit: Lost terminal]
<mort>
when compiling/assembling/linking for RISC-V, you want to emit JAL when the jump target is within the +-1MiB range of the immediate, but immediate + JALR otherwise. How is this actually handled? How and when is the most one picked?
<mort>
imagine the function: 'void bar(int x) { if (x) { foo1(); foo2(); foo3(); ... } }' -- with enough 'fooN()'s, I might have a 600kB 'if' body if the function calls end up being 1-instruction, but a 1200kB 'if' body if the function call ends up being 2-instruction, so whether I can use a relative conditional branch with immediate or not also depends
<mort>
on how exactly the binary is laid out
<mort>
hmm after some experimentation, it seems like real-life compilers will produce inefficient code for every function call, it seems to always use auipc + jr/jalr regardless of whether the auipc is necessary
<mort>
clang produces the auipc+jalr sequence with -flto too tho
<ats>
Are you look at the object file or the binary after linking? It's the linker that converts the call/jump sequences into more efficient forms when possible...
<ats>
(-flto isn't necessary - it works with normal separate compilation by emitting special kinds of relocation to indicate what kind of jump/call it's doing)
<mort>
I'm looking at the object file and the linked binary
<mort>
I had forgotten to compile with -flto so that wasn't actually doing anything, but if it's not supposed to be necessary then that doesn't matter
<mort>
the object file only contains the R_RISCV_CALL relocation, not the R_RISCV_RELAX relocation
<mort>
this is clang from llvm 14.0.6
<mort>
maybe only GNU supports it
<mort>
but that article is useful, and it kind of confirms my thoughts about "if this is all being handled in the linker that's gonna be really messy"
haritz has quit [Remote host closed the connection]
haritz has joined #riscv
haritz has joined #riscv
kailo has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
kailo has quit [Remote host closed the connection]