commit 880a8de6ad2328d9151638d83e1754ca3e1e3a79
author Reid Kleckner <rnk@google.com> Mon Mar 22 14:56:44 2021 -0700
committer Copybara-Service <copybara-worker@google.com> Thu Mar 25 13:33:39 2021 -0700
tree cb21e4a34766fbdfd8870937a09eed9dc5938ed3
parent fb5b54a3af1f0b9c1eb6fdbbce457ad81131a9e6

[COFF] Only consider associated EH sections during ICF

The only known reason why ICF should not merge otherwise identical
sections with differing associated sections has to do with exception
handling tables. It's not clear what ICF should do when there are other
kinds of associated sections. In every other case when this has come up,
debug info and CF guard metadata, we have opted to make ICF ignore the
associated sections.

For comparison, ELF doesn't do anything for comdat groups. Instead,
.eh_frame is parsed to figure out if a section has an LSDA, and if so,
ICF is disabled.

Another issue is that the order of associated sections is not defined.
We have had issues in the past (crbug.com/1144476) where changing the
order of the .xdata/.pdata sections in the object file lead to large ICF
slowdowns.

To address these issues, I decided it would be best to explicitly
consider only .pdata and .xdata sections during ICF. This makes it easy
to ignore the object file order, and I think it makes the intention of
the code clearer.

I've also made the children() accessor return an empty list for
associated sections. This mostly only affects ICF and GC. This was the
behavior before I made this a linked list, so the behavior change should
be good. This had positive effects on chrome.dll: more .xdata sections
were merged that previously could not be merged because they were
associated with distinct .pdata sections.

Reviewed By: mstorsjo

Differential Revision: https://reviews.llvm.org/D98993

GitOrigin-RevId: 7ce9a3e9a91bb0c71cd3560079ff4c31d5dade1b