[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

[cmuellner]

This PR is tracked here: riscv-admin/dev-partners#4

Unfortunately, there were no updates for more than half a year.
Are there suggestions to move this forward? Are there any blockers?

[simonpcook]

I tried integrating this into a LLVM build locally, and there are a couple of issues that need fixing which I've commented on the appropriate lines.

[simonpcook]

1. The loading value of this jalr register is indexing an array of uint8_ts so actually is only getting the least significant bit of rd, so any jalr using anything other than zero/ra will be converted. This isn't being picked up in tests because the encoding of ra is 1.
2. This assumes that the jalr instruction is 4 bytes after the relocation offset. This is true for R_RISCV_CALL, but R_RISCV_JAL relocations are also processed via this function. This means the instruction after the jal instruction is both processed for its bits in the rd field and deleted if the branch target is in the table.

The same issues appear in scanTableJumpEntries, but commented once for brevity.

[math-gout]

According to the RISC-V unprivileged specification (27.14.3. jvt CSR) the jvt section should be aligned to 64 bytes.
"If jvt is writable, the set of values the register may hold can vary by implementation. The value in the
BASE field must always be aligned on a 64-byte boundary."

[RobinKastberg]

This is relevant to my interests, is there anyone working on it? I am happy to help.