The width of the APSInt values should be the width of an element.
getCharByteWidth returns the size of an element in _host_ bytes, which
makes the width N times greater, where N is the ratio between target's
CHAR_BIT and host's CHAR_BIT.
This is NFC for in-tree targets because all of them have CHAR_BIT == 8.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think this is fine, and it's a nice simplification.
However it doesn't seem to do much of anything in practice: if you look at StringLiteral::mapCharByteWidth, supporting different CHAR_BIT would be more involved. And that's just part of the front end.
I really don't how much effort would be involved for complete support, and... well, as you say, we have no way to test anything.
So my feeling is that we can land that because it simplifies the code, but further work into non 8-bits platforms probably require the input of more folks
and a RFC may be warranted.
Looking around non 8 bits CHAR_BIT seems to have been discussed before https://discourse.llvm.org/t/rfc-on-non-8-bit-bytes-and-the-target-for-it/53455
but i don't know if a conclusion was reached. Maybe worth poking that thread if you are interested?
WDYT @aaron.ballman ?
I think this is a good NFC change as it brings us one TINY step closer towards supporting platforms where CHAR_BIT != 8. But I agree with Corentin that a lot more work needs to happen to support that kind of target; restarting the discussion on the linked RFC would be a good idea if you plan to aim for full support.