I'm wondering if there's any other compiler flags that may allow code to be inlined more aggressively. I've tried --optimize
but it doesn't seem to be inlining the thing I want.
The thing I want inlined:
dot = \a, b -> map2 a b Num.mul |> agg Num.add
map2 = \a, b, func -> vec (func a.x b.x) (func a.y b.y) (func a.z b.z)
agg = \v, func -> func (func v.x v.y) v.z
Idealy dot
would be inlined at the call site, but I'd settile for map2
and agg
being inline in the dot function. When I look at the objdump
for the executable though I see this:
The call site:
call 153f0 <Vec3_dot_
and the dot
function:
00000000000153f0 <Vec3_dot_139c9542137b10e977a775e441e04012cc6d2c98579f3cdeb5fb42ef98df6d6>:
153f0: 50 push %rax
153f1: e8 fa 04 00 00 call 158f0 <Vec3_map2_3d7aff37b23cd9f9e6beb177d8bf818babb9d186ea278cc981a34be43b8cf34>
153f6: 58 pop %rax
153f7: e9 84 01 00 00 jmp 15580 <Vec3_agg_bd5db9a62133a57f3c3971868413d37dfa646aa8a2764e7763fd4ba5b0b0d4>
153fc: 0f 1f 40 00 nopl 0x0(%rax)
I don't think the calls to Num.mul
and Num.add
are being inlined either.
That's definitely surprising. I wonder if we are generating strange llvm ir that is breaking inlining. That would surprise me for something simple like this.
the Vec3
type is just a record of x, y, z, that are all some specific numeric type?
Also, if you are willing to compile the compiler, you could try setting this number higher: https://github.com/roc-lang/roc/blob/f1a1f57adfc78be555b8553525fa7ff03d61e15b/crates/compiler/gen_llvm/src/llvm/build.rs#L1137
Yep just a record with x y & z F64
But I would guess that something more fundamental is off that is confusing llvm if simple functions like that aren't inlining
k I'll give that a try
oh and I should mention the roc command I'm using is roc dev --prebuilt-platform --optimize game/test.roc
this Vec3 is in the platform's roc code, which roc dev
also builds right? When it sees what platform game/test.roc
uses
Oh, I think roc dev
ignores --optimize
That's a part of the cli we should definitely fix.
Anyone looking for a good first issue/contributing to hacktoberfest. This should be a great one to grab.
@Richard Feldman should we make the flag work or just remove it from roc dev
? I assume remove, but thought I might as well double check. Important not is that roc ...
and roc dev ...
are technically run the exact same code path. Banning roc dev --optimize ...
sound reasonable. Banning roc --optimize ...
sounds strange.
overall I think we should move in this direction
and in that design there's no roc dev
, just roc
and roc --optimize
so in the meantime I don't have strong feelings about what we do while roc dev
still exists :big_smile:
I thiiink that worked, I can't even find the dot function in the binary anymore :) I still want to compare the code for map2 a b Num.mul |> agg Num.add
vs manally doing \a, b -> (a.x * b.x) + (a.y * b.y) + (a.z * b.z)
, will have to find what happened to that call site...
So for anyone interesting in contributing to this. It has easy progression to a medium sized project. Super small project is just cleaning up --optimize
for roc dev
and roc
subcomands of the compiler. I think for simplicity, we should just make those two flags work.
After that small task, the medium size project would be to revamp the cli in general. Goals here: https://roc.zulipchat.com/#narrow/stream/304641-ideas/topic/Roc.20cli.20workflow/near/451019171
Of note, that can definitely be split into multiple smaller pieces instead of done at once.
Here is the primary issue that @Luke Boswell created back in April: https://github.com/roc-lang/roc/issues/6637
I may get around to creating some child issues, but if I don't do it in time, I can still probably help anyone work on this
Also note that we improved the llvm optimisation passes a lot in the llvm upgrade branch. It's almost ready to land, just needs some CI love and the wasm repl fixed. My plan was to revisit after we land the rebuild host PR. Basically we currently have just a few hand picked passes, but on that branch Folkert helped to use the same as clang for the different opt levels.
@Jared Cone what form is your code in? Is it simple enough to drop into something like the platform switching example? I'd be interested to know if there's any difference using that branch https://github.com/roc-lang/roc/tree/upgrade-llvm-zig
@Luke Boswell yep I'll extract it later and put up a branch
I tried building my app using roc from the upgrade-llvm-zig
branch but I still see my Vec.dot
function not getting inlined when running roc dev --prebuilt-platform --optimize app/app.roc
Brendan Hansknecht said:
Oh, I think
roc dev
ignores--optimize
Can you try that same command with build
instead of dev
@Jared Cone?
Yes build
correctly inlines. I think Luke was asking me to try roc dev --optimize
using a different branch of roc
Yeah, maybe, I'm not sure :big_smile:
I think there was a miscommunication.
The issue we are seeing here is simply the --optimize
flag being ignored. When we properly instruct llvm to optimize, it does so correctly.
Luke's branch may help llvm optimize better, but doesn't fix anything around the --optimize
flag. So I wouldn't expect it to have any effect on this issue.
Yeah I think I misunderstood
Last updated: Jul 06 2025 at 12:14 UTC