Stream: t-lang

Topic: Arbitrary-width integer types: LLVM support!


Josh Triplett (Apr 22 2020 at 15:20, on Zulip):

http://blog.llvm.org/2020/04/the-new-clang-extint-feature-provides.html

Josh Triplett (Apr 22 2020 at 15:21, on Zulip):

Here's hoping we can wire that up in Rust.

lqd (Apr 22 2020 at 15:27, on Zulip):

(hannah shared more details on discord (#design room) but this is mostly news for clang/C, it's always been supported in LLVM IR)

Sebastian Malton (Apr 22 2020 at 16:25, on Zulip):

I assume that https://github.com/rust-lang/rfcs/pull/2581 will use this feature in LLVM

kennytm (Apr 22 2020 at 17:10, on Zulip):

tried performing division using _ExtInt(8192), and clang ICE with "error in backend: Unsupported library call operation!" :upside_down:

kennytm (Apr 22 2020 at 17:13, on Zulip):

_ExtInt(128) is the highest type supporting / and %, as expected.

scottmcm (Apr 22 2020 at 18:32, on Zulip):

While it's always been theoretically supported in IR, it'll probably mean it has fewer rough edge, which is nice.

scottmcm (Apr 22 2020 at 18:34, on Zulip):

I often wish we could have u63 and such -- we have a ton of APIs that take a usize where you're prohibited from setting the high bit

varkor (Apr 22 2020 at 18:46, on Zulip):

there were some suggestions regarding using const generics for arbitrary-width integers, though I can't remember how nice the APIs were

mark-i-m (Apr 23 2020 at 20:48, on Zulip):

Yep, there's a ton of low-level data structures that could benefit from it too. Like taking 9 bits out of a virtual address to index a page table.

Josh Triplett (Apr 23 2020 at 20:57, on Zulip):

I'm dealing with many u48 and u40 values lately.

Josh Triplett (Apr 23 2020 at 20:58, on Zulip):

And in one case, a u34 value...

Lokathor (Apr 23 2020 at 21:02, on Zulip):

The PNG spec says that image dimensions are supposed to be the equivalent of what Rust would call NonZeroU31. And a lot of MMIO would benefit from some sort of bitfields struct support combined with arbitrary width integers.

Amanieu (Apr 23 2020 at 21:05, on Zulip):

I believe this clang extension is completely unrelated to bitfields.

Amanieu (Apr 23 2020 at 21:07, on Zulip):

_ExtInt types are bit-aligned to the next greatest power-of-2 up to 64 bits

So basically these types still use up the same amount of memory as normal integers but have operations on them effectively automatically truncated to a certain bit width.

Josh Triplett (Apr 23 2020 at 21:33, on Zulip):

That would make them helpful for implementing bitfield semantics, though.

simulacrum (Apr 23 2020 at 22:42, on Zulip):

@Josh Triplett Hm, I don't see how that's true? You'd (if I understand correctly) not be able to use these for bit fields because a: u1, b: u1 takes up two bytes still

Lokathor (Apr 23 2020 at 22:44, on Zulip):

It might have to be kinda jiggered a bit on the Rust side of things, where you have a setter that takes a u3 or something and then stores it in a u16or whatever by upcasting it and then shifting it into place and such.

Josh Triplett (Apr 23 2020 at 22:44, on Zulip):

In Rust yes. I meant that with C-style bitfields, you could write _ExtInt(5) fieldname: 5; and you'd have a field that not only takes up five bits, but operates as a five-bit number type.

Josh Triplett (Apr 23 2020 at 22:45, on Zulip):

That would need more wiring up to work in Rust, not least of which, having bitfield support. :)

scottmcm (Apr 23 2020 at 22:46, on Zulip):

no-ref fieldname: u5 ;)

Sebastian Malton (Apr 24 2020 at 01:08, on Zulip):

I sort of like how zig did this, they allow references to bitfields by encoding the offsets in the type

Last update: Jun 05 2020 at 23:05UTC