Valid section or chunk alignments are powers of 2 in the range [1,
8192]. These can be stored more canonically in log2 form to free up some
bits in Chunk. Combined with D61696, SectionChunk gets 8 bytes smaller.
Details
- Reviewers
ruiu aganea - Commits
- rZORGa25ce58dd92e: [COFF] Store alignment in log2 form, NFC
rGa25ce58dd92e: [COFF] Store alignment in log2 form, NFC
rG1a5cc629debd: [COFF] Store alignment in log2 form, NFC
rLLD361206: [COFF] Store alignment in log2 form, NFC
rL361206: [COFF] Store alignment in log2 form, NFC
Diff Detail
- Repository
- rL LLVM
Event Timeline
lld/COFF/Chunks.cpp | ||
---|---|---|
860 ↗ | (On Diff #198721) | I'd think we should always pass a power-of-two instead of log2 to constructors for the sake of consistency. |
lld/COFF/Chunks.h | ||
47–48 ↗ | (On Diff #198721) | Is this enforced by the file format? |
73 ↗ | (On Diff #198721) | If this can be triggered by feeding a bad file, this should be a call of error() instead of assert(). |
136 ↗ | (On Diff #198721) | Instead of emphasizing that the maximum alignment is 2^13, can we support an alignment up to a reasonable upper limit, say, 2^32? That's apparently large enough, and by doing that, we do not have to explain a trivia that what value is the maximum alignment value we can express by COFF. (And the runtime cost of doing that is virtually nothing.) |
lld/COFF/Driver.cpp | ||
1744–1745 ↗ | (On Diff #198721) | Can you eliminate {set,get}Log2Alignment and consistently use {set,get}Alignment, so that the details about how it is represented internally is hidden from the user? |
lld/COFF/Chunks.h | ||
---|---|---|
47–48 ↗ | (On Diff #198721) | Yes there's a hard limit in the SectionCharacteristics, see PE Format |
In the long term, I think we want to hoist section characteristics up into chunk, and that's going to create the 8192 max alignment constraint. This is just a first step to refactor the code to use the accessors.
lld/COFF/Chunks.h | ||
---|---|---|
73 ↗ | (On Diff #198721) | I don't think it's possible. I think it might be possible with -aligncomm or -functionpadmin, though, since those raise alignment on the command line and take arbitrary input. |
136 ↗ | (On Diff #198721) | Originally I was planning to make this a bitfield, in which case, the comment is relevant, but if we store the characteristics in the on-disk format here, then this comment isn't really needed. It makes more sense to move it to the setter, since that has to deal with the edge case of invalid alignments. |
By the way, the other idea I had in mind for this problem is to define a new integer-ish class that can hold only a 2^n value, by overriding cast from/to an integer. I don't know if that is a good idea or a disgusting idea, though.
Well, the next logical step, IMO, is to store the section characteristics directly in Chunk. I don't think that would work well with the custom type idea.
LGTM
lld/COFF/Chunks.h | ||
---|---|---|
70 ↗ | (On Diff #198920) | A little off-topic, but llvm::Log2_32 seems to be a redundant function, as I think we can just use countTrailingZeros. |