Previously the 'Padding' argument was the number of padding
bytes to add. However most callers that use 'Padding' know
how many overall bytes they need to write. With the previous
code this would mean encoding the LEB once to find out how
many bytes it would occupy and then using this to calulate
the 'Padding' value.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
The new function may write more bytes than PadTo bytes, so it seems the only reliable way of using it is to pass 5 as PadTo. Is there any other use case than that?
include/llvm/Support/LEB128.h | ||
---|---|---|
22–24 ↗ | (On Diff #113928) | It is perhaps a matter of personal taste, but it feels Len is a better name than PadTo. I'd also add a comment that if an encoded number of shorter than Len bytes, it is padded so that it becomes Len bytes in total. |
My understanding is that with LEB one can pad to any number of bytes. We use 5 when we write 32-bit values in wasm because 5 is the number of bytes required to encode any 32-bit number as an LEB. We likewise use 10 bytes when writing padded 64-values. One might conceivably use 2 and 3 when writing 8-bit and 16-bit values as well.
Looks good to me. This is certainly a simplification over computing PaddingFor5ByteULEB128 :-).