I think once @jrtc27 confirms all her issues are addressed this is good to land.

LGTM, thanks.

It looks like others are reviewing the implementation details, but I just wanted to chime in to say that this looks like a useful feature for the RISC-V backend too. Currently we set CostPerUse for some registers in order to tweak register allocation in a way that benefits codegen when the compressed instruction set extension is enabled. Although the impact is _very_ minimal, this slightly harms targets that don't support the compressed instruction set (admittedly, this isn't really true of any shipping RISC-V processor so not a big concern). It would be good to use this vary the CostPerUse depending on target RISC-V features.

No objections accepting from the RISC-V side. I don't have a set of execution tests for the fshl/fshr changes to validate them, but I didn't see anything obviously wrong. The changes primarily affect the (still experimental) bitmanip extension also, so the bar for review is somewhat lower. The change does seem to improve srliw lowering in a few places in the GCC torture suite as well (in a way that is both correct and beneficial).

The description of isNotDuplicable in MachineInstr.h is:

/// Return true if this instruction cannot be safely duplicated.
/// For example, if the instruction has a unique labels attached
/// to it, duplicating it would cause multiple definition errors.
bool isNotDuplicable(QueryType Type = AnyInBundle) const {
  return hasProperty(MCID::NotDuplicable, Type);
}

I don't think this obviously applies to CSRs, and the property doesn't seem to be applied to instructions that modify control registers for other in-tree targets.

Thanks for spotting this one - LGTM.

@jrtc27 are you happy with this patch in its current form or are there outstanding issues to be addressed?

@jrtc27 are you happy with this patch now? Thanks for your review on this and thanks @msizanoen1 for providing this fix.

In D79870#2153608, @simoncook wrote:

It's a shame this just missed the creation of the llvm 11.0 branch, do we think it's worth trying to get this backported since it only just missed?

LGTM, thanks!

I'm getting a test failure on rv64-relax-all.s with this patch?

Hi @jrtc27 - it would be nice to get this in before LLVM 11 branches. Will you have time to add the extra comment and commit today?

This looks good to land IMHO. It's a nice improvement for RISC-V, and it seems to have been sufficiently reviewed by people active with the DAGCombiner. Thanks Roger.

LGTM, thanks!

I've added some suggestions to clarify the code comments. I think before landing it would be good to address the crash Sam pointed out for an invalid -march, but otherwise I think this looks good to me (at least, it seems worth landing this and if further issues crop up we can fix them and request them for merging into the LLVM 11 branch).

This broke the build for -DBUILD_SHARED_LIBS=True. I've committed rG5282a6186c which fixes it for me.

Let's go for it! Thanks.

This LGTM from a RISC-V perspective. I'll likely follow up with a RISC-V test case similar to the SystemZ one post-commit, but given this is really fixing a cross-platform ABI issue this seems non-urgent. Thanks for spotting and addressing this issue.

Got it, thanks. In that case LGTM and please tweak the commit message (the last paragraph specifically) so it's clear that the two changes are interlinked.

This looks good to me, good catch. I do see a codegen change on regstack-1.c from the GCC Torture Suite, so it might be worth having a quick look to see if it's easy to make a test case based on that.

This is a nice simplification, thanks. My only request before committing is to split out the RISCVTargetMachine to a separate pass, as that is logically distinct.

LGTM, +1 on adding a comment to the expansion functions noting the need to update getInstSizeInBytes. Thanks!

I've gone through and can't see any obvious issues. I defer to one of the RISC-V Vector extension usual suspects for giving a LGTM on the detail of the altered instructions etc. Once we have that, this looks good to land IMHO.

This has been hanging around for a while, but I think we'd basically agreed this is the right logic. The comments have ended up referring to flags that don't exist on Clang making it a little hard to follow, and I've added a request to slightly expand testing. If you make those cleanups I think it should be ready for a final review and merge.

Looks good to me, thanks for catching this.

In D69987#2079524, @rogfer01 wrote:

The patch as it stands now LGTM and I think it can be committed. Is there any objection remaining?

Any further comments @simoncook @asb?

Thanks, this looks good to me. I wasn't aware of MakeLibCallOptions and IsSoften - I think I've wanted something like that before.

In D79155#2088191, @efriedma wrote:

Please add a comment explaining what OffsetInRecord means; then LGTM.

Ping on this. The patch still applies cleanly against current HEAD.

I think there's value in adding these tests (I note libatomic in GCC has a similar set of simple functionality tests), and this seems a sensible way to do it.

Disclaimer: I haven't swotted up on these constrained intrinsics to review the proposed lowering yet, but added a quick note on the setOperationAction calls. I agree with Luis the test cases would probably be easier to read if using the hard float ABI. I think you're lacking any test coverage for f32 as well.

Sorry for the delay on this - the lockdown situation is really hurting my review time, though it looks like my childcare situation will improve from the week after next.

Good catch, thanks for the fix! The logic was incorrectly written assuming isFloatingType would return false for complex values which is of course incorrect.

Please check D79928 which cleans up the visibility of all of these overridden methods.

I'm in favour of merging a patch that is functionally correct and makes incremental improvements. I'd rather avoid any regression in codesize though if possible. How feasible would it to be to avoid that case? It may be worthwhile leaving some of the materialisation improvements for a follow-up patch in order to land the clear wins now.

Thanks, this looks good to me. PreSched2 is logically a better place for the standard pseudo expansions, though I'm not seeing any codegen changes at all with e.g. the GCC torture suite. But I'm happy to land this as-is.

Could you rebase please? This isn't applying cleanly for me on current master.

Looks like this landed while I was composing the below:

Hi Paolo. I'm sorry this has been left hanging for some time. On the one hand, with this being an experimental feature and purely additive the bar for merging is slightly lower than e.g. a rewrite of all our existing codegen patterns (which could cause new regressions). On the other hand, this pre-commit review is realistically going to be the time when the codegen patterns and associated tests get most scrutiny and it would be a shame to skip that.

Thanks, this is a good improvement. Two thoughts, mainly for discussion rather than blocking issues:

Thanks Sam. I left a few minor comments inline. From looking at the diff in compiler output on the GCC torture suite, I do see a few cases where there is a potential regression. e.g. loop-ivopts-2.c, which represents a case where the stack adjustment is large, but doesn't overflow the 12-bit immediate fields of addi and s[d|w]. The prologue and epilogue are both two instructions and become three instructions with this patch (although it is a code size win).

Just to understand the current status with respect to GCC, am I right that support for these attributes is not in upstream GCC? @kito-cheng is there any plan to upstream?

LGTM, thanks. Left an inline comment pointing out a TODO that can now be removed thanks to this.

LGTM, thanks. Left one tiny nit inline.

In D78907#2012362, @lenary wrote:

In D78907#2012344, @asb wrote:

LGTM. Minor nit: using %0 and %2 as the only two named values seems odd though? Most other tests in test/CodeGen/RISCV use a/b/... for arguments and %0/%1/%2/... in the body.

I generated the testcases in Clang (actually using godbolt, but it's doing the same IR lowering as clang HEAD is), which is why the arguments don't have names. I can re-introduce them if that's easier.

LGTM. Minor nit: using %0 and %2 as the only two named values seems odd though? Most other tests in test/CodeGen/RISCV use a/b/... for arguments and %0/%1/%2/... in the body.

LGTM, thanks!

Sorry to ask you to move things back, but I think the debug CSR tests would make most sense in machine-csr-names.s on the basis that the privileged spec does list those CSRs in the "machine-level CSR names" table.

Updated patch to include full context.

Thanks for the patch, as we discussed last week I think supporting dret with the same ease as the privileged instructions is the right path. Given dret is defined in the debug spec rather than the privileged spec, could you please:

• Move the test to a new test file debug-valid.s
• Move the DRET instruction definition to a new section of RISCVInstrInfo.td with an internal header like

//===----------------------------------------------------------------------===//
// Debug instructions
//===----------------------------------------------------------------------===//

I've approved D65649 now, so I think this one can land as soon as that one does.

I think we should land this and continue further development in-tree. There might be a few minor refactorings I want to propose after the fact, but these shouldn't block this going forwards.

I can see the argument for changing the default of EnableRVCHintInstrs. Might we be better just doing that, and keeping it as "rvc-hints" to avoid adding negative features?

Thanks Simon, LGTM. I noted a tiny nit re the test file.

In D65649#1943856, @simoncook wrote:

I agree, it seems more like a sketch of what they should be, but the mentioning of the size improvements suggested to me perhaps they should be, since evaluating the potential "what the final B extension should look like" it probably should be included. There is the question of where this should be enabled, my first thought (which this patch implements) is Zbb because it seemed the most logical, but maybe given the instructions stated state does another subextension make sense for its evaluation? These are all experimental so I think there's some leeway to some option, but I think it would be good to land it if we think people may be using it/want to evaluate it. I suspect there's many valid routes with this being experimental, we just need to choose one we have concensus around making sense. Perhaps a topic for today's call?

Submitting the comments I have so far - need to continue going through in more detail.

This is a much simpler fix! Looks good to me.

I'm reviewing this with an eye to merging it, but one big thing that comes to mind is the compressed instructions. The draft bitmanip spec describes these under "Future compressed instructions" and says "It presumably would make sense for a future revision of the “C” extension to include compressed opcodes for those instructions." My reading is that this is more of a sketch of potential encodings and a less firm proposal than the 32-bit encodings described elsewhere in the spec. Do you disagree with that assessment?

Thanks for the patch. I added a couple of nits - please rename the test file to thread-pointer.ll to match what other backends do and make it more discoverable. Also, although there different is minor we do use update_llc_test_checks.py for essentially all RISC-V tests so it would be good to use that for thread-pointer.ll as well.

I was thinking about making it clearer why this cast is necessary. The first thought was obviously to add a comment to explain (similar to the comment in your review description). But maybe there's an argument for adding a small helper? Although it would literally just be doing a cast, it's name and description should make it much clearer what is going on. I don't feel super strongly about that approach though - so do speak up if you disagree!

This LGTM, thanks Luis!

In D75168#1909097, @luismarques wrote:

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.

I'm not sure that's something we want to do. Those are reserved for HINT instructions. The spec says:

This HINT encoding has been chosen so that simple implementations can ignore HINTs alto-
gether, and instead execute a HINT as a regular computational instruction that happens not to
mutate the architectural state.

If the core truly supports those HINTs then it shouldn't trap. If we are trapping presumably it's because the core is just executing the HINT as a plain load/store. That would typically be a NOP, but the address must be invalid and so we are trapping. In that case we are correctly identifying it as a READ or WRITE.

In D65649#1931064, @simoncook wrote:

This is starting to look good. I've checked all the encodings, and other than c.zext.w having the wrong value all the encodings are right.

One thing I would consider is to make reviewing/future changes easier, I would define all the instructions in the order they appear in the Chapter 2.11 Opcode Encodings tables. This way, it will be easier to see for future revisions what has changed and make sure the encodings are up to date. This might end up with a few more let Predicates = directives, but we can rearrange and tidy this up when it is all ratified.

LGTM, thanks Simon!

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.

LGTM, thanks!

Hi Dylan - on the mailing list thread for this I raised a concern about disassembler support based on comments I'd seen in a recent patch. Can you please clarify the current status there?

Yes, if @jrtc27 commits I'd be supportive of a cherry-pick to the release branch.

In D68964#1884580, @davidlt wrote:

Yes, please backport (if possible) all other related changes mentioned above (if they are not yet part of 10.0).

This would help distributions to avoid hacking LDFLAGS / build systems files while building LLVM/Clang stack on Linux.

@hans this patch fixes a reported bug https://bugs.llvm.org/show_bug.cgi?id=42984 and is non-invasive. I'd be in favour of cherry-picking for 10.0 if you're ok with that.

Great fix, thanks @jrtc27. Please do go ahead and commit.

In D68964#1882377, @hans wrote:

In D68964#1880966, @smeenai wrote:

CC @hans for 10.0

+asb from code_owners.txt, what do you think?

Thanks for implementing this - I'd personally like to see the psABI proposal https://github.com/riscv/riscv-elf-psabi-doc/pull/131 merged before merging into LLVM/LLD.

@MaskRay, @ruiu, would you be in favour of this being backported to 10.0?

I've filed a request to merge this into the release branch here https://bugs.llvm.org/show_bug.cgi?id=44631 - thanks for the fix James!

This looks good to me, thanks James. I had a closer step through of the logic here to convince myself.

Thanks for the fix! As Sam says, explaining the issue in the commit message would be useful.

In D67495#1811715, @lenary wrote:

In D67495#1800935, @luismarques wrote:

LGTM. My only concern was if it made sense to use the same statistic to count in both places, and if we could end up double counting the instructions emitted (now, or in a future LLVM version). After a quick look I didn't really see other targets using the same approach, but I also can't think of a way where this ends up actually being problematic.

My understanding is that instructions only go through one of these functions. RISCVAsmParser.cpp is used by the assembler only, and the RISCVAsmPrinter.cpp is only used by LLVM CodeGen. This should mean that instructions are not double-counted (today). Yes I'm not sure why we have both, I think @asb did this to ensure better layering.

LGTM, thanks.

Please update the check so it checks the error location too, like we do for other *invalid.s checks.