Jared Cone (Oct 08 2024 at 00:31): Jared Cone (Oct 08 2024 at 00:31):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.
Brendan Hansknecht (Oct 08 2024 at 00:42):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.
Brendan Hansknecht (Oct 08 2024 at 00:42):the Vec3 type is just a record of x, y, z, that are all some specific numeric type?
Brendan Hansknecht (Oct 08 2024 at 00:44):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
Jared Cone (Oct 08 2024 at 00:44):Yep just a record with x y & z F64
Brendan Hansknecht (Oct 08 2024 at 00:44):But I would guess that something more fundamental is off that is confusing llvm if simple functions like that aren't inlining
Jared Cone (Oct 08 2024 at 00:45):k I'll give that a try
Jared Cone (Oct 08 2024 at 00:46):oh and I should mention the roc command I'm using is roc dev --prebuilt-platform --optimize game/test.roc
Jared Cone (Oct 08 2024 at 00:47):this Vec3 is in the platform's roc code, which roc dev also builds right? When it sees what platform game/test.roc uses
Brendan Hansknecht (Oct 08 2024 at 00:50):Oh, I think roc dev ignores --optimize
Brendan Hansknecht (Oct 08 2024 at 00:50):That's a part of the cli we should definitely fix.
Brendan Hansknecht (Oct 08 2024 at 00:52):Anyone looking for a good first issue/contributing to hacktoberfest. This should be a great one to grab.
Brendan Hansknecht (Oct 08 2024 at 00:54):@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.
Richard Feldman (Oct 08 2024 at 01:45):overall I think we should move in this direction
Richard Feldman (Oct 08 2024 at 01:45):and in that design there's no roc dev, just roc and roc --optimize
Richard Feldman (Oct 08 2024 at 01:46):so in the meantime I don't have strong feelings about what we do while roc dev still exists :big_smile:
Jared Cone (Oct 08 2024 at 02:08):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...
Brendan Hansknecht (Oct 08 2024 at 02:34):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.
Sam Mohr (Oct 08 2024 at 04:33):Here is the primary issue that @Luke Boswell created back in April: https://github.com/roc-lang/roc/issues/6637
Sam Mohr (Oct 08 2024 at 04:34):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
Luke Boswell (Oct 08 2024 at 05:50):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.
Luke Boswell (Oct 08 2024 at 07:04):@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
Jared Cone (Oct 08 2024 at 14:44):@Luke Boswell yep I'll extract it later and put up a branch
Jared Cone (Oct 08 2024 at 17:20):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
Anton (Oct 08 2024 at 17:27):Brendan Hansknecht said:
Oh, I think
roc devignores--optimize
Can you try that same command with build instead of dev @Jared Cone?
Jared Cone (Oct 08 2024 at 17:40):Yes build correctly inlines. I think Luke was asking me to try roc dev --optimize using a different branch of roc
Anton (Oct 08 2024 at 17:41):Yeah, maybe, I'm not sure :big_smile:
Brendan Hansknecht (Oct 08 2024 at 18:27):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.
Luke Boswell (Oct 08 2024 at 19:02):Yeah I think I misunderstood
Last updated: Jul 26 2025 at 12:14 UTC