[PATCH] D86847: [Bitcode] Add BITCODE_SIZE_BLOCK_ID to encode the size of the bitcode

[Teresa Johnson via Phabricator via llvm-commits]

tejohnson added a comment.

In D86847#2250194 <https://reviews.llvm.org/D86847#2250194>, @MaskRay wrote:

> In D86847#2250027 <https://reviews.llvm.org/D86847#2250027>, @steven_wu wrote:
>
>> In D86847#2248354 <https://reviews.llvm.org/D86847#2248354>, @MaskRay wrote:
>>
>>> In D86847#2248353 <https://reviews.llvm.org/D86847#2248353>, @steven_wu wrote:
>>>
>>>> I am a bit worry that linker might concatenate bitcode file with padding to achieve alignment requirement, etc. I guess you can create a termination block to mark the end but it is hard to seek the next start.
>>>
>>> We can set the section alignment to 1 to avoid padding: (I rushed a bit, sorry: 6ae7b403c3e1aebcb825d3dd4777d3c1149d6d67 <https://reviews.llvm.org/rG6ae7b403c3e1aebcb825d3dd4777d3c1149d6d67>)
>>
>> I didn't see that. I don't really have concerns then.
>>
>> In D86847#2248516 <https://reviews.llvm.org/D86847#2248516>, @dblaikie wrote:
>>
>>> @bartell mentioned something about a bitcode wrapper that does provide the length - how does this patch's strategy compare to that approach? Are they redundant? Should the wrapper be replaced with this patch's approach? (or should the bitcode wrapper approach be used instead of adding this patch?)
>>
>> I guess that is an implementation choice. This approach prefers a simple linker implementation, while the bitcode wrapper requires linker know to treat this section differently and write bitcode wrapper into section.
>> @MaskRay Do you have any specific use case in mind for this? If you are tied to a linker like `lld`, it might be better just teach `lld` to treat this section differently so we don't need worry about concatenated bitcode file.
>
> It is not tied to a linker like lld. I believe in most binary formats, if you specify an alignment of 1, their linkers will concatenate input sections in the output without padding. Actually, the section content of .llvmbc is entirely opaque to lld/GNU ld/gold. ("dumb linker, smart format" design).
>
> If the bitcode wrapper requires the linker to understand its format, I'd vote against that solution. (It will not work with GNU ld/gold.)

Per @bartell 's last comment, it sounds like it doesn't require the linker to understand the format (the handling is on the bitcode reader/writer side). Do we know whether that would work here instead?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86847/new/

https://reviews.llvm.org/D86847