@javedabsar (or @javed.absar) I seem to recall you have experience with schedulers. If you could give us a hand here that'd be great! :)

Now that you're at it, could you also update the doxygen comments in ScheduleDAGRRList::{AddPredQueued, AddPred, RemovePred} because they don't return a boolean now.

In D47927#1652507, @nikic wrote:

IMHO this should land as-is, and setcc folds can be implemented additionally if there are other places where they would be useful. My rationale would be that it is better to directly perform a simpler lowering than a complex lowering that then gets optimized. (Basically: If you can reduce the size of the implementing code and get a better result, then I think we should always be doing that.)

ChangeLog:

• Refresh RISC-V and X86 tests

Thanks for the review @jrtc27 and apologies for the delay. I had forgotten I had posted this.

ChangeLog:

• Remove unneeded runtime check and turn it into an assertion.
• Avoid instruction aliases in testcase
• Strengthen check directives for the NORELAX case.

Thanks for the review @luismarques

Thanks for the review @lenary @luismarques

Thanks for the review @luismarques

In D47927#1622957, @lebedev.ri wrote:

Yes

Thanks for the clarification @asb. I've posted D66003 (depending on D66002) for that.

In D47927#1621986, @lebedev.ri wrote:

Hmm, while there, just to point out the obvious, the another approach here would be to teach DAGCombine/TargetLowering::SimplifySetCC() about these folds.
That is explicitly one of a few valid reasons to add optimizations into backend 'instead' of middle-end.

ChangeLog:

• Combine if-else logic.
• Adjust subtraction comment to is (non-zero) positive to avoid ambiguity.

ChangeLog:

• Constrain fold to i1.

ChangeLog:

• Tighten even more the condition in which the fold is applied
• Rephrase comments so they mention brcond.

ChangeLog:

• Tighten conditions in which the fold is executed
• Use isBitwiseNot instead of checking for (xor e, 1)
• Remove TheXor
• Rephrase comments so they are less confusing by not mentioning br.

Thanks @asb @lenary for the review!

ChangeLog:

• Make ilp32d also the default in 32-bit RISC-V Linux
• Do not use nested conditional expressions

Not relevant anymore.

Thanks @lenary ! I will commit this shortly.

ChangeLog:

• Update AMDGPU test.
• Add RISC-V tests to show that we fold the xor in the branch.

I've committed rL367698 - you should be able to use the update script now

Thanks @efriedma. I will commit this shortly.

ChangeLog:

• Remove RISC-V dependent expansions
• Simplify current target-independent expansion of S{ADD,SUB}O. Not considering U{ADD,SUB}O anymore.
• Update tests that saw codegen changes after this

ChangeLog

• Rebase change

Hi @lenary, sure I can rebase this.

Thanks @lenary !

ChangeLog

• State on top of which commit of libcxx's copy we are cherry-picking.

Thanks a lot for the guidance @lebedev.ri. I wasn't aware of @lenary change and the other copies.

ChangeLog:

• Cherrypick D64237 to other existing copies of cycleclock.h

As noted in another comment, it's not entirely clear what zero-width bitfield behaviour to match (see here) as GCC seems buggy and the ABI is under-specified. Ideally I'd like to land this patch and follow-up to adjust the zero-width bitfield behaviour if necessary once that psABI issue is resolved.

Thanks @lewis-revill this LGTM.

I have a question about the meaning of the vlen operand so I want to double-check here.

In D45181#1488084, @luismarques wrote:

@rogfer01 Are you still looking into this? My efforts to fix the problem with the debug information would also touch this. How do you want to proceed?

I've been looking into this and I have some observations, but not a satisfactory solution so far.

James, Alex: Thanks a lot for the comments. I'll look into what I can do here.

I don't like resurrecting old reviews. This is just a warning in advance of a future issue we will have with the RISC-V backend when exception handling is enabled (it is not yet upstream).

Thanks a lot for the review Alex!

ChangeLog:

• Improve comment with wording kindly suggested by Alex Bradbury

Lewis, Alex: thanks for the review.