Anton (Dec 02 2024 at 11:42): Anton (Dec 02 2024 at 11:42):I'd like to get some input on #7287:
Currently
testing_roc_allocin crates/compiler/builtins/bitcode/src/utils.zig ignores the value passed as alignment and always returns a pointer to memory with alignment 1. This caused me a few hours of confusion trying to test an allocation that needed aligning.
Ideally, it would align to whatever value is passed (up to that supported by Zig), but allocating with an alignment not known at compile time seems hard (?).
Always aligning to 16 and panicking if a higher alignment is requested seems like it would cover all likely cases (without wasting too many bytes)
Richard Feldman (Dec 02 2024 at 12:32):that idea seems fine to me! :+1:
Oskar Hahn (Dec 02 2024 at 12:34):Here is a discussion about roc_alloc that might me relevant: #platform development > roc_alloc and alignment
Matthew Heath (Dec 06 2024 at 17:45):OK, here is that implemented. I don't think I have the permissions to make a pull request
Matthew Heath (Dec 06 2024 at 17:52):Technically it is aligning as whatever @alignOf(usize) is. Making it 8 on arbitrary hardware is probably possible, but it's trickier and there isn't an obvious benefit.
Brendan Hansknecht (Dec 06 2024 at 18:00):It should align to 16. That is for u128.
Matthew Heath (Dec 06 2024 at 18:07):Oh yeah, I even said 16 in the original post. Long week.
OK. The decallocate is going to have to assume it has access to the 16 bytes before the data starts, but that's fine right?
Anton (Dec 06 2024 at 18:12):OK, here is that implemented. I don't think I have the permissions to make a pull request
You can make a pull request if you fork first
Matthew Heath (Dec 06 2024 at 18:51):Anton said:
OK, here is that implemented. I don't think I have the permissions to make a pull request
You can make a pull request if you fork first
So I can! Here is the PR!
Last updated: Jul 26 2025 at 12:14 UTC