[PATCH] D113865: [COFF] Keep temporary symbols in object files on ARM64, as IMAGE_SYM_CLASS_LABEL

Mon Nov 15 13:08:12 PST 2021

mstorsjo added a comment.

In D113865#3132307 <https://reviews.llvm.org/D113865#3132307>, @efriedma wrote:

> The alternative here is that instead of relying on the symbols defined in the assembler source, we could automatically define a symbol every megabyte.  If we expect the linker is throwing away the symbols anyway, though, the only effect on compiler-generated code is the number of symbols in the intermediate object, which isn't a big deal, I guess.  We typically generate a lot of code labels, though.  Do you have a number for how much we're inflating a typical object file?

I guess it's hard to define what a typical object file is, but from a sample of 5 large-ish and normal sized object files, they grew by 13%, 13%, 10%, 5% and 1%. So clearly notable and not ideal, but not totally out of the question either.

In D113865#3132312 <https://reviews.llvm.org/D113865#3132312>, @efriedma wrote:

> In D113865#3132268 <https://reviews.llvm.org/D113865#3132268>, @rnk wrote:
>
>> Is it possible to relativize these relocations against the most recent previous external symbol instead? Given that the code compiles with function/data sections, that seems like it would work.
>
> This isn't any guarantee there's an external symbol in range, in general.

Yeah. I haven't studied the sequence ordering of what's fixed at what point in WinCOFFObjectWriter, but I'm wondering if the layout is known and fixed at the point when deciding whether to define a symbol or not - I'm afraid it isn't. If it was, we could choose to keep temporary symbols only when the previous external symbol is too far away.

The idea of producing extra symbols with 1 MB intervals sounds neat, but I'm wondering if it's possible to do that at the same time while doing choosing what symbols to define. Or maybe we can still add more symbols after fixing the layout? Then that would work.

But then, when doing the loop for fixing relocations, would that increase the complexity of that loop from O(n) into O(n^2), or at least O(n log n), as we have to search for the best symbol as reference point for each of them. Then again, if it only happens when the default choice is too far away, I guess it would be rare?

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113865