In D157458#4646407, @arsenm wrote:

Post-selection code should not be tolerant of registers without a class. It is unequivocally a bug for a used register to pass selection without a class dead or not

Rebased and dropped comment change

@qcolombet I've updated the comment. Do you think we still need to modify X86FastPreTileConfig? In the latest version we disable this pass for GlobalISel because it was intended for the code selected by FastISel. It's unclear whether we need it with GlobalISel in the future or not.

Updated a comment and rebased

@qcolombet ping

Rebased

In D152332#4489290, @pengfei wrote:

I think the expected behavior is to diagnostic this problem from the front end. I didn't look into details, but guess you may be able to do it in SemaChecking.cpp.

Rebased and updated a comment

Change the comment to say that only alive registers are guaranteed to have a regclass.

Just curious, in RFC we have -mavx10.x-256/-mavx10.x-512 but here we refer to -mavx10.x/-mavx10.x,-mavx10-512bit. Is it compliant with GCC, or the revision is just for the illustrative purpose?

Use X86FastPreTileConfigPass only with FastISel

Moved from a ll test to a more illustrative mir test.

Typo

Return nounwind attribute missed during the last rebase.

Rebased

Hi @pengfei @RKSimon, what do you think about such diagnostic improvement? It works perfectly with clang, however llc ignores errors in a handler and continues execution. It seems that we need a combination of diagnostic and report_fatal_error to stop both clang and llc. Or is it expected behavior of llc?

Rebased and removed FIXME

Addressed the comments.

In D146494#4339563, @pengfei wrote:

@e-kud do you want me to commit if for you? Or you are waiting for another approval?

Rebase. Spelling.

Rebased

Great! Thanks. LGTM.

LGTM. Thanks!

Maybe a few more vector tests? Existing tests cover the no-nans and no-signed-zeros case, they were added to avoid bloat of scalarization. E.g. a test with all checks (generic vectorized version) and two test with constant vectors to eliminate a zero check and a NaN check.

LGTM. Thank you!

LGTM. Glibc tests pass (I haven't checked correspondence of qnan/snan though).

Good catch! Missed that we don't need to check Y on NaN because it is already a result of min therefore we can get rid of NaN loading.

In D145634#4295747, @skatkov wrote:

In D145634#4295568, @e-kud wrote:

In D145634#4294388, @skatkov wrote:

In D145634#4294383, @skatkov wrote:

In D145634#4294264, @e-kud wrote:

In D145634#4291019, @skatkov wrote:

I have a side question (not delaying landing this one)

It looks like this change lowers vectorized form of intrinsic in a non-optimal way.
So I wonder whether there are some plans to improve it as follow-up?

Yes, for sure. I've tried to find a way to implement vectorized version for SSE, but nothing's come to my mind. We need at least SSE2 for PCMPEQ{W,D} because all fp comparison instructions treat -0.0 and 0.0 as equal. It seems that pentium3 will suffer from not optimal fmaximum/fminimum...

Why we cannot do something like this https://godbolt.org/z/Yxfn3jTj1 ?
I mean at least for avx?

BTW. my measurements on micro benchmarking (I know micro might cause that branch predictor works good), the version https://godbolt.org/z/rEj9GPfnY is the best one for scalar but it cannot be implemented in SelectionDAG as has a CFG.

Both versions are incorrect. They don't work as expected in case of (-0.0, 0.0), (0.0, -0.0) inputs. Because comiss and max treat negative and positive zeros as equal.

Take a look carefully. In case of equality we check the sign of the first value. Thus comparison using ucommis is ok.

In D145634#4294388, @skatkov wrote:

In D145634#4294383, @skatkov wrote:

In D145634#4294264, @e-kud wrote:

In D145634#4291019, @skatkov wrote:

I have a side question (not delaying landing this one)

It looks like this change lowers vectorized form of intrinsic in a non-optimal way.
So I wonder whether there are some plans to improve it as follow-up?

Yes, for sure. I've tried to find a way to implement vectorized version for SSE, but nothing's come to my mind. We need at least SSE2 for PCMPEQ{W,D} because all fp comparison instructions treat -0.0 and 0.0 as equal. It seems that pentium3 will suffer from not optimal fmaximum/fminimum...

Why we cannot do something like this https://godbolt.org/z/Yxfn3jTj1 ?
I mean at least for avx?

BTW. my measurements on micro benchmarking (I know micro might cause that branch predictor works good), the version https://godbolt.org/z/rEj9GPfnY is the best one for scalar but it cannot be implemented in SelectionDAG as has a CFG.

Fix single line if style.

In D145634#4291019, @skatkov wrote:

I have a side question (not delaying landing this one)

It looks like this change lowers vectorized form of intrinsic in a non-optimal way.
So I wonder whether there are some plans to improve it as follow-up?

Rebased.
Excluded refactor of half.ll.

Rebased.
Added nounwind attribute to tests.

Rebased.
Uncommented existing tests for the intrinsics.
Addressed to comments.

@RKSimon @goldstein.w.n ping

Rebase

Rebased

Rebased

Support i686 target: can't use integer representation of double -0.0

Addressed comments.
Added comments.
Fixed negative value search in case of undefs.
Updated tests.

Updated tests with undefs.
Use not only splat vector constants.

Addressed the comments.

New tests

@RKSimon @goldstein.w.n ping.

In D145634#4195338, @pengfei wrote:

In D145634#4194990, @e-kud wrote:

In D145634#4187914, @pengfei wrote:

In D145634#4187888, @e-kud wrote:

In D145634#4183847, @pengfei wrote:

Do you have plan to support minimumNumber?

Sorry, I didn't get it. Could you be more specific?

It's accompanying function of minimum in IEEE-754 2019, it will be introduced in new C/C++ standard too. I thought you are working for that.

I can't find any lib calls or specific intrinsics for them. I'd like to add them separately if we have any users or needs of them, do we?

I heard glibc is supporting them. I'm fine with leaving it to the future. Do you have plan on the vector support?

Addressed formatting comments.
Check f16 explicitly even if avx512f16 implies avx512dq for now.

Broke formatting for premerge checks

In D145634#4187914, @pengfei wrote:

In D145634#4187888, @e-kud wrote:

In D145634#4183847, @pengfei wrote:

Do you have plan to support minimumNumber?

Sorry, I didn't get it. Could you be more specific?

It's accompanying function of minimum in IEEE-754 2019, it will be introduced in new C/C++ standard too. I thought you are working for that.

Rebased.
Moved from combine to lowering.
Supported f16 version.
Added optimization for avx512dq.
Added and updated tests.

In D145634#4183847, @pengfei wrote:

Do you have plan to support minimumNumber?

Rebased.
Supported cases with nsz and nnan.
Updated tests.

LGTM. I second that masked versions should be handled as well. I thought they have TP equal to perms but I've double checked and it seems that masked shuffles have TP=0.5 comparing to perms.

Rebased.

Rebased and added a bitcast of IsNOT.

Added vector splitting

In D138521#3974292, @RKSimon wrote:

Do we have any 256/512 bit test coverage?

Propose more generic approach using vector_shuffle

Rebased on precommit tests

Update tests with old codegen

Add peeking through bitcasts for BROADCAST as well.

Address to comments and put tests into https://reviews.llvm.org/D138734