and we then call the copy constructors like this:

void *local_addr = ...;
for (kmp_uint32 u = 0; u < sizeof_copy_infos; ++u)
  local_addr = copy_wrapper_list[u](copied_obj_list[u], local_addr);

ChangeLog:

• Rebase

Thanks again @thopre !

ChangeLog:

• Rebase

ChangeLog:

• Rebase

Thanks for the patch @thopre ! I've got a comment above.

ChangeLog:

• Remove unnecessary return of the insertion point and update code accordingly.

In D69828#1761133, @jdoerfert wrote:

Also for taskwait inside untied tasks we should be reusing the available global_tid instead of calling __kmpc_global_thread_num again.

FWIW, We will just clean up in a later pass (under review). We have to do that anyway, adding some smarts here is barely worth it and I also removed similar logic from my patches.

ChangeLog:

• Enable the new code generation in codegen tests using taskwait

ChangeLog:

• Update patch against changes in D69785

Apologies I screwed my Herald rule!

I'm building clang + openmp like this

Isn't that already done by virtue of the uses of llvm-objdump -d - in the existing tests?

I think we will want decoding tests as well, at least one for instruction.

We have started tallying the instructions against the spec. So far we have found the following missing instructions:

In D69987#1742381, @rogfer01 wrote:

We have started tallying the instructions against the spec. So far we have found the following missing instructions:

• vdot.vv / vdotu.vv / vfdot.vv

It may be possible to halve the number of instructions if we make use of the IsOptional attribute and we always add a mask operand to the instructions that may have a mask. This way we don't have VADD_VV and VADD_VV_T, only VADD_VV with a mask operand whose register is RISCV::NoRegister if the instruction is not masked.

Hi, thanks a lot for this.

Thanks for the review @luismarques . I plan to commit this shortly.

In D69785#1733233, @jdoerfert wrote:

In D69785#1732951, @rogfer01 wrote:

I made a small experiment lowering a taskwait (which is even simpler than barrier in "lowering" complexity). It was pretty straightforward after all.

Nice, can you share the code? Was it based on the OpenMPIRBuilder (this one or the old one) or somehow separate?

Hi @jdoerfert, thanks a lot for putting this up this initial skeleton and providing an example with barrier.

@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.