Currently we keep an internal buffer of device memory that is used to
indicate ownership of a port. Since we only use this as a single bit we
can simply turn this into a bitfield. I did this manually rather than
having a separate type as we need very special handling of the masks
used to interact with the locks.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Sad to see this isn't a type. Part of the point of encapsulating the indexing and mutation ops is the inbox outbox arrays could also be bitmaps.
Even without that, there's no reason to open code the division and modulo ops. Please put those behind named functions. Set nth bit or similar.
libc/src/__support/RPC/rpc.h | ||
---|---|---|
88 | This isn't the size of the bitmap. I don't know what a bitfield is. Bits per word? I'm not convinced we should pretend this stuff works for atomic types other than plain integers. How about a static assert that atomic uint32 is the same size as a uint32 and write 32 here? |
Some nits. Still thinking about the tradeoffs between a type and functions but leaning in this direction
libc/src/__support/RPC/rpc.h | ||
---|---|---|
59–60 | Maybe rename this while we're in the area, it's a maximum port count, not a default. Could static assert that it's a multiple of 32 | |
161 | available | |
248 | the bitshifted boolean is probably ok - bool << unsigned probably promotes to an unsigned op - but could you either cast the cond or assign it to a uint32 before the expression to remove the ambiguity? | |
258 | UINT32_MAX or ~0u please |
This may have broken the staging buildbot that tests libc on GPU https://lab.llvm.org/staging/#/builders/247/builds/3201
Unsure, did some basic checks and it seems to be working now on HPE. Going to do a git pull on both RONL and HPE systems to be doubly sure.
Maybe rename this while we're in the area, it's a maximum port count, not a default. Could static assert that it's a multiple of 32