RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-October/145850.html

Looking into the origin of this problem, git bisect points at cb82de29601 but I don't think it is the culprit. Looks like we may have been a bit unlucky during register allocation with the new sequence of instructions.

ChangeLog:

• Forgot to add the test for RISC-V

Out of curiosity, what is your approach? Carrying around a bool Scalable flag?

I have applied all feedback, but I have proposed an alternative approach to the one suggested by @rengolin in one of the comments, for static methods like ElementCount::get[Non]Scalable.

Hi @fpetrogalli, thanks for this proposal.

Thanks all for the review, I'll land this shortly.

ChangeLog:

• Rebase

ChangeLog:

• Remove dubious branch using undef. Use a plain ret void instead.

In D83750#2149682, @lenary wrote:

Are we sure we want to branch on undef to one of two unreachables?

I suppose we cannot use ret as we don't have a non-constant to return anyway.

Given this shows a change in the behaviour of D81805, I'm happy for this to land.

ChangeLog:

• Remove assert

ChangeLog:

• Update test from D83750

Apologies, I totally forgot about this one. I'll update it ASAP.

Would it make sense to still expand these constructs late (e.g. renaming RISCVExpandAtomicPseudoInsts.cpp into RISCVLateExpandPseudoInsts.cpp) still using PreInstrSymbol?

I'm sorry to report that this approach is still problematic. In some of the testcases of the LLVM test-suite the pass when built with -fPIC -O3, pass Branch Probability Basic Block Placement decides to copy the AUIPC / LD pair but the copies carry around the same symbol. This fails with:

Thanks a lot @lenary, this seems a much better approach.

In D79635#2125510, @luismarques wrote:

In D79635#2124242, @nathanchance wrote:

This patch breaks compiling the Linux kernel:

Thanks for the detailed bug report. I have addressed this by temporarily reverting the part of this patch that wasn't NFC. This should solve the problem for now, if not please let me know.

I have been unable to come up with a test that shows any change (I may check LNT to see if something changes), so ideas are welcome here.

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

@HsiangKai: just to confirm and to avoid confusion for other reviewers.

Tail-predication is a new form of predication in MVE for vector loops that implicitely predicates the last vector loop iteration by implicitely setting active/inactive lanes, i.e. the tail loop is predicated. In order to set up a tail-predicated vector loop, we need to know the number of data elements processed by the vector loop, which corresponds the the tripcount of the scalar loop. We would like to propagate the scalar trip count to the backend, so that this can be picked up by the MVE tail-predication pass.

Thanks for the review @lenary!

ChangeLog:

• Remove new hasOneUse and assert opcode of operand.

ChangeLog:

• Refresh

ChangeLog:

• Remove whitespace prior committing

Thanks a lot for the review @luismarques !

ChangeLog:

• Use fmv.{w,d}.x / fcvt.d.w instead

A quick check with the GCC 10 in Fedora Rawhide shows the following results for this small testcase

ChangeLog:

• Rebase

ChangeLog:

• Rebase

2.) Optimization passes and (vectorizing) frontends
Vectorizers/frontends should query TTI to decide whether they should be using %evl.
For VL targets, the loop vectorizer could use %evl to implement tail loop predication (as in the DAXPY example https://www.sigarch.org/simd-instructions-considered-harmful/ , linked by @lkcl).
For non-VL targets, you should make the iteration mask the root mask of all other predicates in the loop and set %evl to -1.

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: