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.

ChangeLog

• Remove dead phi in the test

Thanks for the update Alex, certainly vararg.ll is a better test to update than my earlier suggestions.

Hi Luis,

Thanks Alex. I will commit it shortly.

Thanks a lot for this Alex.

Looks good to me, just a minor suggestion above.

@asb in D59298 I call riscv::getRISCVABI for ClangAs, does it make sense to make the same change for Clang here?

Looks sensible to me.

@jmorse pr40427.ll uses x86-specific bits in the CHECK lines and is causing failures in builds that do not target by default x86 (e.g. http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/16847 )

Hi @lewis-revill, thanks for the patch.

Ah, I think what happens is that we should not emit such patterns without the presence of the F extension: these patterns are ultimately selected as instructions in F. Does this make sense?

Hi Alex,

Hi Alex,

In D54143#1325501, @lewis-revill wrote:

Rebased and updated to use and expand PseudoLLA for PC-relative addressing.

Minor comment above but other than that this looks good to me too.

The build issue was fixed in rL348783

Hi all,