I'm no longer working on this. AFAIK this task and D46946 have been reassigned to @Jianping or @LuoYuanke.

Is clang part good to go too?

Implemented suggested changes.
Regarding masking with select - do you mean creating new avx512_padds/avx512_psubs intrinsics without masks and replacing the old calls with new intrinsic+select?

I added it to InstCombineCalls.cpp after @craig.topper's suggestion to do so in order to enable adding more optimizations besides constant folding in the same place.

Split to two different patches for signed and unsigned intrinsics.
Corrected version number.

Removed signed intrinsics lowering due to the pattern being too complicated - instead some minor optimizations were introduced on LLVM side.

Brought back signed intrinsics and added constant folding in InstCombine.

Now the pattern is not detected if there are any undef elements in the constant operand.
I removed the tests added after fixing the bug which caused reversion of the patch - in the meantime the pattern conditions changed and the sequence used in those tests is now perfectly valid.
Should FIXME comments be removed?

Removed unnecessary comment.

Rebased and implemented suggested changes.

Ping.

Ping.

In D48705#1147074, @efriedma wrote:

I'm not sure D46946 and D47019 are good ideas in the first place, particularly D47019. Expanding an intrinsic to an 8-instruction sequence is getting past the point where we're actually getting any benefit from transforming intrinsic to native IR. Emitting a complicated lowering like that, and trying to recover it in isel seems very tricky to get right, and as far as I can tell we don't get much benefit.

If we are going to expand out x86 shift and rotate intrinsics, we should probably consider pattern-matching on IR, rather than waiting for SelectionDAG. Trying to work around isel limitations in this fashion is fragile, and will probably have a wider effect than you want.

For rotates, there was a proposal to add a generic IR intrinsic for variable rotates on llvmdev, due to the complications involved in late pattern-matching.

Ping.

Fixed rounding mode calls.

Ping

LGTM

Removed CHECK-NOTs for consistency.

Whoops, that's a wrong revision. I'll revert it shortly.

Added missing scalar intrinsics without rounding.

Added missing scalar intrinsics without rounding.

Added lowering of scalar sqrt intrinsics without rounding (relies on D47621).

Mask scalar case is closed and doesn't have any effects on this revision. Besides, I resolved issues connected to lowering scalar sqrt intrinsics without rounding (that is, if D47621 is accepted). Should I add them here to have everything sqrt in one place or upstream this and add them to a new revision?

Added a check for two constant operands. I'm still waiting for answer for my last question.

Added fast-isel tests - there are some XORs/MOVs which aren't combined but it doesn't look terrible overall.

In D47443#1114187, @RKSimon wrote:

You're going to hate me for this, but we could do with -fast-isel test files covering the builtin test files codegen on the clang side

Fixed fma mask3 pattern.

Test diffs are now visible.
Note: there is no test for div in combine-select.ll - div pattern gets split into 3 basic block with a branch condition, so this optimization doesn't apply to it.

In D47012#1106702, @RKSimon wrote:

Add these tests with the current codegen so the patch shows the diff improvement?

Nevermind, I got it wrong - after compiling something similar to https://bugs.llvm.org/show_bug.cgi?id=37417, it does split the pattern. Moreover, it splits it in different manner for different intrinsics and hoists more than one more instruction, so it might not be as simple as moving back than one subtraction in the bug reproducer. I don't think there is any other way though - replicating simplifyX86immShift and simplifyX86varShift directly in IR would be a nightmare.

Because emitting shifts in IR is more complicated than just adding an shl/lshr node due to those poison values (see D46946) and would create some redundant code. I guess I can use simplifyX86immShift directly instead of emitting a call here.
As for the bug - much more than one instruction gets thrown out of the loop after applying shift lowering patch - I'm leaning to leaving only non-variable intrinsics in this patch and implement variable ones after the generic intrinsic is introduced.

Added missing test checks.

Can you provide an example of such behavior? I tried various (rather simple) tests like this one:

Added tests for ISelLowering combining and FMA patterns.

Yes we could, but only for X86ISelLowering folding and FMA patterns - the other ones are multiclasses without any definitions, so they never alter anything at this point. They are intended to be a basis for several upcoming patches which will add defms for these patterns with the tests alongside them. I'm OOO tomorrow so I'll be able to add the tests for first two cases on Monday.

About lib/Target/X86/X86ISelLowering.cpp:36183 - does it make sense to emit normal ADD/SUB without saturation when element type after truncation is larger than before extension?

I brought back lowering in AutoUpgrade for unsigned intrinsics, although I'm not sure if there's a universal agreement about it. In email correspondence @DavidKreitzer
suggested that it would be better to retain the intrinsics and get rid of them in another time/patch, which Craig disagreed to and argued we can lower non-complex ones (like addus/subus) without much trouble. Is there a consensus about it?

As was decided, I removed lowering in Autoupgrade.cpp. I also moved the tests into corresponding *target*-intrinsics-canonical.ll files as discussed with @mike.dvoretsky. I added tests for PR37260 in test/CodeGen/X86/avx2-intrinsics-canonical.ll.
What's your opinion on fast-isel subus emmision and my proposition in detectAddSubSatPattern function?

Nevermind - these four are not strictly truncating. Sorry for the confusion.

There are four other similar intrinsics which convert to 128/256-bit vectors:

During internal review I proposed something like that (~0 - a) < b ? ~0 : a+b.
It gets rid of zext/trunc in addus pattern but introduces additional subtraction which is presumably more costly. Your solution seems much better, I'll change it to that form.

About test/CodeGen/X86/avx2-intrinsics-fast-isel.ll change - there is a canonical form for subus pattern I'm using here - it's different from adds/addus/subs patterns. While those three use ext/trunc pattern and fold correctly, subus has only max+sub. If fast-isel is enabled, sub is not put into SelectionDAG - that's what prevents it from combining. Instead, it's appended after isel as a lowered node. Is there a machine instruction pass for combining?

We're currently discussing the possible solutions for the JIT pipeline issue with @DavidKreitzer.