.

LG, but not sure if the comment should mention -static. I think bfd's comment is better

Update comments

In D54442#1334641, @courbet wrote:

In D54442#1331367, @MaskRay wrote:

It looks I missed the unittest, sorry for that.

I don;t see the unit test in the patch.

Add comment about FreeBSD .note.tag

Forget to upload test file...

gold

However, it's still useful to define them as hidden in many contexts.

simplify

It looks I missed the unittest, sorry for that. And I somehow messed ToProcess[Tail++] = Q;. The test can be simply repaired. What should I do if I don't agree that an additional abstraction layer should be added?

.

Never mind. Someone asked me for reviews of the llvm-exegesis patch series. I said it wasn't necessarily to be done that way and thus created this one. Later that patch series got accepted and merged and they even mentioned . Yes, I don't understand why that patch series changed the same place back and forth.

Rename RelrRelocationType

This was undefined behavior before C++17 and indeterminate since C++17...

It is a cleanup..

Reminder for committing :)

Use specific type

.

In D55234#1325804, @dblaikie wrote:

In D55234#1318754, @ruiu wrote:

I think you should focus on large programs. We don't really care about the marginal improvements or regressions for small programs because linking small program is very fast anyway, and we don't care about 10ms improvements or regressions. For large programs, it seems reasonably positive. Also this patch only deletes code.

FWIW linking times on smaller (than the very large) programs like Clang are still significant to many folks (including LLVM developers themselves) - for example when running "ninja check-all" many LLVM tools (~30? I forget roughly how many) have to be linked - and saving time on each (or the longest one) means getting out of that very serial step in the check run (massively parallel compiles, serial links, then massively parallel test runs).

In D55484#1324983, @bkramer wrote:

The performance difference on preprocessing huge files was tiny back then, doesn't surprise me that it disappeared. What did you test this on?

Friendly ping

The one-entry cache I mentioned is like the following (I don't say I suggest doing that as it is so complicated with probably so little value):

I didn't notice this patch when I sent out D55248 (I just observed a locally-invented upper_bound without a good justification :) ).

Add llvm::

In D55248#1318096, @grimar wrote:

I think this kills the additional optimization we have here. Unfortunately, I do not remember
how much improvement this piece had in comparison with the simple code as your patch has,
but this was the code initially implemented by Rafael in r284594, which comment says:

Add a faster binary search.

Even with the hash table cache, binary search was still pretty
hot. This can be made even faster with prefetching.

Idea from http://cglab.ca/~morin/misc/arraylayout-v2/

I will suggest moving this to llvm.

I do not know if that was moved to llvm (or if that what we might want atm, if not).

In D53238#1318349, @martell wrote:

Seems like a better solution than what I had in D37726.
I'm not sully sure on the naming so I think someone else should also sign off on this.