[RISCV][LLD] Add RISCV zcmt optimise in linker relaxation

[Xinlong-Wu]

This patch is moved from https://reviews.llvm.org/D134600 .
Considering that the LLVM's Phabricator instance has been replaced by a static archive, it is not workable to review on Phabricator anymore. So I reopened this pr and synchronized the latest changes.
I can't reopen previous pr #68551 because the previous branch has been recreated

This patch implements optimizations for the zcmt extension in lld.

A new TableJumpSectio has been added.

Scans each R_RISCV_CALL/R_RISCV_CALL_PLT relocType in each section before the linker relaxation, recording the name of the symbol.

In finalizeContentsthe recorded symbol names are sorted in descending order by the number of jumps.

Optimise and insert a new cm.jt/cm.jalt during the relax process. in the process, we reused theR_RISCV_JAL relocType

co-author: @ScottEgerton

[Xinlong-Wu]

I tried linking several common applications and libraries using this patch to compare Zcmt's contribution to reducing Code Szie.

The results can be found in the Sheet or in the image below.

Besides that, I found a problem that needs to be discussed.

In TableJumpSection::finalizeContents(), the linker will abort the tbljal optimization and empty the Jump table if tbljal optimization would cause a negative optimization (i.e., the size reduction caused by the Table jump Inst is less than the size increase caused by making the Jump Table).

However, the linker still adds the symbol __jvt_base$ to .symtab . This results in a small increase in program size.

Thus, I tried to delay adding the symbol __jvt_base$ at lld/ELF/Writer.cpp and remove the symbol __jvt_base$ when the Jump Table is not empty. Something like that

But it will crash with error placeholder symbol reached writer at lld/ELF/Symbols.cpp:154. Does anyone can point out anything else should I do to add symbol delay?

[github-actions]

✅ With the latest revision this PR passed the C/C++ code formatter.

[MaskRay]

Code size reduction | 0.14% | 0.08% | 0.15% | 0.22% | 0.19% | 0.38%

Let me express my gratitude for the dedicated work you put into measuring the impact. This has been useful to figure out how useful an extension is.

As an established code size reduction feature, global pointer relaxation seems to have a saving larger than this but still needed a lot of discussions whether it was justified (since the numbers aren't great either). The zcmt numbers seem smaller while the implementation is much heavier in assembler/linker and table jump seems to get questions on hardware side whether the little code size saving justifies probably significant performance overhead. I also heard that zcmt is incompatible with another extension. It would be greatly beneficial to see a more substantial commitment from hardware vendors, given the drawbacks, minimal saving, and the considerable implementation complexity.

[asb]

The RISC-V code size reduction work-group did some analysis of expected code size improvements from zcmt https://docs.google.com/spreadsheets/d/1bFMyGkuuulBXuIaMsjBINoCWoLwObr1l9h5TAWN8s7k/edit#gid=1679419155 - it would be worth understanding why the results seem so different.

[kito-cheng]

In TableJumpSection::finalizeContents(), the linker will abort the tbljal optimization and empty the Jump table if tbljal optimization would cause a negative optimization (i.e., the size reduction caused by the Table jump Inst is less than the size increase caused by making the Jump Table).

Add a testcase to demonstrate that?

[Xinlong-Wu]

I'm trying remove the symble .riscv.jvt when Jump table is empty, But I have noticed .shStrTab has been fixed befor relaxation. I can't remove it from string table. string .riscv.jvt in .shStrTab will always cause a negative effect

[JackGittes]

finalizeEntry seems not modifying any section members and the input EntryMap?

[Xinlong-Wu]

we actually do following 3 things

1. sort the EntryMap as decrease order by size reduction of each item in EntryMap
2. drop rest if EntryMap larger then maxSize
3. drop the item that have a negative effect