LGTM. But please give it some time for other people to chime in before you merge, they may disagree with this .inc approach.
I'm approving this assuming the generic test is actually ran against this implementation. @kamleshbhalui did you verify that was the case?

When I said earlier that you should provide a muldi3 test I was saying that under the impression that there wasn't one already. It seems that there is already a target-indepent test. Sorry about that. My point was that the test did NOT have to be RISC-V specific. The generic test is gated on librt_has_muldi3. For that to work with lit automatically, your implementation files have to have the correct name. See compiler-rt/test/builtins/CMakeLists.txt, specifically the comment saying "hexagon/udivsi3.S" => "udivsi3". Others can comment on what is the best/cleanest way forward:

I think it would make sense to merge this with the mulsi3 implementation, since it's the same sequence of instructions.
Like the mulsi3_test.c, you should provide a test for this. The mulsi3_test.c was provided as a RISC-V-specific test, but there doesn't seem to be anything RISC-V specific in the test, so it should probably just be a generic test (hat tip to Alex Bradbury for noticing that). Likewise, the same would go for your muldi3 test.

Rebase. Now also handles the case of ConstantPoolSDNode.

It might be a good idea to add more targetted tests for this. See llvm/test/CodeGen/PowerPC/no-pref-jumps.ll and some of the tests added in 940ab934d42.

In D79492#2024394, @asb wrote:

1. I don't want to unreasonably expand the scope of this patch, but I do note that at least the srli transformation may be beneficial on RV32 as well for code size (still two instructions, but more compressible). Did you consider adding this or look at other RVC considerations?
2. Although it has the advantage that mistakes in edge cases etc won't lead to regressions in terms of longer instruction sequences, I'm slightly wary of the "generate and see if it's shorter" approach. Though perhaps this is going to come way down the list on any compile-time profiling vs all the other analyses+transformations being done. Any thoughts on this?

LGTM. Nice to see this extraneous addi go!

This is superseded by D79492, which subsumes this special case with more general optimizations.

Add one more test case.

LGTM.

LGTM

LGTM. I would prefer a hardfloat ABI to make the test slightly cleaner.

LGTM.

LGTM.

Fix whitespace.

Merged the */README.LLVM change entries, as having separate entries for a single LLVM commit could be confusing.

• Also apply a cherrypick that minimizes LLVM lint formatting issues;
• List the cherrypicks in benchmark*/README.LLVM;
• Update summary accordingly.

In D77912#1976893, @MaskRay wrote:

OK. I benchmarked __udivsi3. That version is actually slightly faster than D77744. I moved that function to int_div_impl.inc

I think this makes sense and is correctly implemented but I would like other people to look at this.
It would also benefit from adding tests, rejecting the "minimally installed" scenario and accepting the proper install.

Thanks for the fix Jessica.
Looking at, say, doAtomicBinOpExpansion it's not immediately obvious why some of those values are correct. Can you please provide more info, ideally in the code?
Is there really no way to provide tests for these?

I think this looks good. I'll let @lenary have another look.

In D77117#1952272, @shiva0217 wrote:

For the downstream RISCV maintenance, it would be easier to inherent the RISCVISelDAGToDAG and only override the method need to customize for the custom provider ISA extension without touching RISCVISelDAGToDAG.cpp which may cause conflict when upgrading the downstream LLVM version.
I think it could be helpful for other RISCV downstream maintenance. Could it be the sufficient reason to split out the header?

LGTM. Thanks!

Please add tests.

Fix copy paste issue in the updated patch.

Properly handle compressed reserved instructions.

Ping.

Hey @jrtc27 . Is there anything blocking this patch being committed?

LGTM!

In D75729#1917843, @jrtc27 wrote:

Unless you fast-path register zero (or the value itself being zero), a naive implementation is going to have to do a full integer->float conversion, which is more likely to be a multi-cycle operation, regardless of rounding mode. Contrast that with an fmv, which is a special case of fsgnj, but the generic case is still just bit selection and concatenation, so it should always be single-cycle. Having said that, the Rocket schedule (and reading the code) indicates that both are 2-cycle operations, and for the Bluespec Piccolo/Flute cores both are 1-cycle operations, but the GCC schedule for the 7 series SiFive cores claims that fmv will be in the A pipe (address, i.e. loads/stores, but also any FP<->int given that already needs to be present on the load/store paths), and fcvt will be in the B pipe (branches, but also mul/div and and any other FP ops).

Actually I got confused, fmv.x.?and fmv.?.x aren't special cases of fsgnj (that's only true for the FP<->FP fmv's), but their own instructions outright. The rest of what I said still applies though.

I'm happy to use those fmv.{s,d}.x instead.

In D75729#1912792, @rogfer01 wrote:

Perhaps these are slightly better than just fcvt everywhere because they avoid the rounding mode required by fcvt.s.w / fcvt.s.l / fcvt.d.l?

LGTM.

GCC seems to use fmv.s.x / fmv.d.x (the former of which now should be called fmv.w.x? ) instead of fcvt, not sure why. A quick Googling returned:

In D75168#1907941, @asb wrote:

There are some cases where you need to perform more checking in order to be future proof for possible new standard extensions. Specifically, review the RVC Instruction Set Listings in the RISC-V spec and check for where an encoding is marked as "RES" (reserved). e.g. C.LWSP is valid only if rd!=0, and the version with rd=0 is a reserved encoding. Similar with C.LDSP. I think it's just those two.

Closing revision.
(My commit message clean-up went overboard and accidentally deleted the Differential Revision line).

LGTM.

Fix preprocessor conditional compilation block conditions.

As suggested by @efriedma, the patch was reworked to have one target with native atomics, and one without. No RUN run with a default target remains.

In D66870#1885778, @jas-onleo wrote:

Hello，Can you tell me the resaon why it wasn't support for risc-v before ? Why not add the support for rv32 this time?

In D68964#1884694, @asb wrote:

It's unfortunate, but as Hans says this series of patches is likely too much at this stage in the release process. If there's a 10.0.1, perhaps it makes sense there. They benefit the RISC-V community, but there's a risk of regressing somewhere else in a way that's probably not fair to other targets and their release testers.

In D68964#1884578, @hans wrote:

Oh I see. I've backed it out again in d75ce45777d9802d43b555993fde8ed6562fb368, this is too much stuff to land so late. I think it can wait until the 11 release.

In D74847#1883028, @efriedma wrote:

I'm not really a big fan of running tests with the host target triple, anyway; it seems to create work with almost no benefit. I'd be happy to just run the test with one target that has native atomics, and one target that doesn't. (The relevant code is all target-independent, aside from the atomic widths, so we aren't really gaining anything by testing more targets.)

In D68964#1882946, @asb wrote:

The backport request seems ok to me, assuming you're happy taking a patch like this at this stage in the release process.

Thanks for the insight @Meinersbur .
This patch broke some ARM builds, I'll re-land it after solving that.