LGTM

I'm not sure I know enough about debug info to approve this myself. I just knew enough to know that the comment didn't match up after the change.

Looks like objdump also prints the memory on the right in at&t syntax. So this makes our disassembler printing consistent

Did this come out of the folding table work? The real bug is that TEST8rm is wrong. But we don't notice because we have aliases to accept the memory operand in either location.

This is apparently a revert of the fix for https://bugs.llvm.org/show_bug.cgi?id=22995

LGTM

Was the code not using emmintrin.h and instead copied code from it that used the builtins?

I don't think we should shrinking operations based on undef inputs. I think we should be shrinking them based on what elements are consumed by their users. There's no reason the shuffles in these reductions have to have undef elements. For integers we may rewrite the shuffle mask to undef in InstCombine if the elements aren't used down stream. But we don't do that for FP.

LGTM

Why can't we just generate the table by default and not include it yet? Then anyone can look at the table at any time without having to do something extra?

Why can't we just generate the table by default and not include it yet? Then anyone can look at the table at any time without having to do something extra?

I havent' found any piece of code that analyzes SUB_REG_TO_REG that closely. Everything I found pretty much treats it much like a copy. Does anyone know of anything that cares today?

Remove from X86InstrFragments.td

I did remove the usages from the td patterns. It wasn't used in very many places.

Why this be solved by just combining extract_subvectors through things like binops and onto their inputs.

Here's the comment from getVectorMaskingNode

What sort of test are you looking for? The truncate intrinsic tests should already cover this.

LGTM

PR28540 is fixed now.

Ping

So I think we all agree that doing sinking in InstCombine isn't a good idea in the long term. But I suspect doing something to fix that is going to take some more work.

LGTM

Ran with ENABLE_EXPENSIVE_CHECKS and llvm.X86TargetMachine.isMachineVerifierClean and got the same failures as PR27481

LGTM

LGTM

Not sure what happened there. That was clearly the wrong patch

Use getVectorShuffle

Is it the PadToColumn calls that are slowing down the formatting?

I'm going to go ahead and remove __builtin_ia32_pbroadcastq512_mem_mask from clang and change _mm512_maskz_set1_epi64 to be disabled in 32-bit mode. I want to nominate this for 5.0.1 because using it in 32-bit mode causes the compile to throw a cannot select error. So disabling it in the header at least gives a better user experience.

Convert the AVX2 integer intrinsic as well.

Move AVX2 unary shuffle check to the top of the function.

LGTM

Ping

Ping

Is the code gcc generates at O3 really "better"? According to godbolt the resulting assembly looks quite large with lots of spills and reloads.

Here's something even closer to the real benchmark https://godbolt.org/g/ePkjTu

Looks like machine sinking fails because it can't handle the cmovs reading eflags. And it only considers one instruction at a time, but to sink the cmov you have to sink the eflags producer and the cmov together.

Ok so maybe I'm chasing a deficiency in machine sinking? Here's a related example https://godbolt.org/g/YnEvgg Most of the code should have been able to sink below the 'je' at line 11.

Here's a longer version of what I saw in the benchmark i was looking at

Remove a stray change that snuck in

LGTM

Normal loads are usually folded by isel patterns
Stack reloads created by the register allocator are folded using the load folding tables. Since these loads don't exist during isel we can't fold them there.
The peephole pass can also fold loads using the loading fold tables. At one point in time this was definitely weaker than the isel mechanism even ignoring the missing instructions in the isel table. I'm not sure what the status is now.

Oops you are correct. Sorry.

Forgot to add full context to the diff the first time.

Remove the builtins from BuiltinsX86.def

/Can you update the avx2-intrinsics-fast-isel.ll test too? It should use the native IR implementation now instead of the intrinsic. It's supposed to match the IR clang will generate.

LGTM

LGTM

This also seems to be only a partial diff now.

This also seems to be only a partial diff now.

LGTM

LGTM