This is an archive of the discontinued LLVM Phabricator instance.

Change encodeU/SLEB128 to pad to certain number of bytes
ClosedPublic

Authored by sbc100 on Sep 5 2017, 4:01 PM.

Details

Summary

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.

See: https://reviews.llvm.org/D36595

Diff Detail

Repository
rL LLVM

Event Timeline

sbc100 created this revision.Sep 5 2017, 4:01 PM
sbc100 added a subscriber: llvm-commits.
ruiu edited edge metadata.Sep 5 2017, 4:12 PM

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.

sbc100 added a comment.Sep 5 2017, 4:33 PM

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.

ruiu added a comment.Sep 5 2017, 4:38 PM

Ah, that makes sense.

sbc100 added a comment.Sep 6 2017, 3:16 PM

@sunfish could you take a look?

sunfish accepted this revision.Sep 8 2017, 4:03 PM

Looks good to me. This is certainly a simplification over computing PaddingFor5ByteULEB128 :-).

This revision is now accepted and ready to land.Sep 8 2017, 4:03 PM
This revision was automatically updated to reflect the committed changes.