In D104178#2815069, @RKSimon wrote:

LGTM - does this need to be back ported to 12.x?

Fixed typo in comment

LGTM

LGTM

I don't what Intel's original failure looked like, but here's a test that should reproduce this with -run-pass=machinelicm https://reviews.llvm.org/P8267 needs more cleanup.

It would be nice to have a test, but this change seems ok.

In D104061#2811804, @rnk wrote:

That's a good point, if this attribute disables vectorization of integer math, the docs should say as much.

This matches my understanding too. At least on X86, I think "floating-point" also includes integer SSE. Should we mention that?

LGTM

Are evl1 and evl2 likely to be the same value? Do you have an example when they would be different?

LGTM too. Other than the last comments from Fraser and I.

In D73607#2806917, @rtrieu wrote:

I ran across a llvm_unreachable that points to this commit. Repro instructions below:

test.ii

double compare1(double x, double y) { return ((int)x< y) ? x : y; }
double compare2(double x, double y) { return y != 0.0 ? y : x; }

int compareint(int x, int y, int z) { return (x < y) ? y : (z < x) ? z : x; }

class C {
public:
  C(double arg) { 
    constexpr int k1 = -(1 << 23); 
    constexpr int k2 = (1 << 23) - 1;
    array[0] = compareint(arg, k1, k2);
  }
  
  char array[3];
};
extern "C" double round(double);
constexpr double kEight = 8;

C create(int b) {
  double d1 = b * kEight;
  double d2 = round(d1);
  double d3 = compare1(0.0, d2);
  double d4 = compare2(0.0, d3);
  return C(d4);
}

void loop(int* b, C *ptr, long j) {
  for (int i = 0; i < j; ++i)
    ptr[i] = create(b[i]);
}

clang command:

clang \
"-cc1" \
"-triple" "x86_64-unknown-linux-gnu" \
"-emit-obj" \
"-target-cpu" "x86-64" \
"-target-feature" "+avx" \
"-target-feature" "+avx2" \
"-target-feature" "+avx512f" \
"-O3" \
"-vectorize-loops" \
"-x" "c++" "test.ii"

output:

PromoteIntegerResult #0: t177: v16i24 = X86ISD::VTRUNCS t216

Do not know how to promote this operator!
UNREACHABLE executed at llvm-project/llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp:54!

0.	Program arguments: clang -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -target-cpu x86-64 -target-feature +avx -target-feature +avx2 -target-feature +avx512f -O3 -vectorize-loops -x c++ test.ii
1.	<eof> parser at end of file
2.	Code generation
3.	Running pass 'Function Pass Manager' on module 'test.ii'.
4.	Running pass 'X86 DAG->DAG Instruction Selection' on function '@_Z4loopPiP1Cl'

LGTM

LGTM

LGTM. Thanks!

LGTM

Use AVL instead of GPR. Use VLOpFrag

RISCV changes LGTM

LGTM

LGTM

LGTM

In D103820#2803120, @davezarzycki wrote:

Actually, wait. Something weird is going on at the mid-level. These two functions should generate the same optimized IR, right?

typedef int V __attribute__((vector_size(64)));

V lt_zero_x_y(V mask, V x, V y) { return mask <  0 ? x : y; }
V ge_zero_y_x(V mask, V x, V y) { return mask >= 0 ? y : x; }

In D103743#2802747, @benshi001 wrote:

In D103743#2802540, @luismarques wrote:

Are you planning on extending this to use bclriw on RV64? (Would that clash with the use of tablegen? Personally, I tend to find C++ custom lowering of longer stuff easier to read and more cohesive, not sure how others feel)

I have not consider BSETIW/BINVIW/BCLRIW, maybe I will do it in next patch. And this patch will just focuses on BCLRI.

I do not like C++ custom lowering for that, since it needs even more lines than current form.

The examples in the V spec show no spaces. Are you going to update that too? What about binutils?

I just noticed that this enabled interleaving in the loop vectorizer even when the V extension isn't enabled. So we now generate interleaved scalar code in some cases. Was that intentional?

clang-format

In D103510#2800595, @HsiangKai wrote:

In D103510#2798999, @frasercrmck wrote:

My browser's really chugging on this huge patch so my input has to be brief. Maybe we could hide the test changes for now?

Regarding vmv.v.i, is there not already some support for rematerialization (e.g. of immediates)? Or is it non-trivial due to having to manage VSETVLIs?

There seems no support for rematerialization for vmv.v.i. Do you mean to set isReMaterializable = 1, isAsCheapAsAMove = 1 to vmv.v.i pseudo instructions?

LGTM

Rebase

LGTM