Besides, I found a strange thing:
In PPCTargetLowering::LowerFP_TO_INT, we will return original op if the input type is fp128, which means in some subtarget , fp128's fptoint is legal and have corresponding instructions.
But what you are going to do is to do a hack and expand it to libcall at the beginning of legalizeOp(...). It seems there is a conflict here.

Could we check whether the input type is fp128 at the begining of PPCTargetLowering::LowerFP_TO_INT and if it is a fp128 input type, we directly ConvertNodeToLibcall?

Ping?

Modify some comments and remove unnecessary lambda function

Fix the warning raised by Lint

With avx512f, the cost of SK_Select(v32i16 or v64i8) should be 1(vpternlogq)

In D87884#2287025, @craig.topper wrote:

In D87884#2287015, @yubing wrote:

In D87884#2286958, @craig.topper wrote:

In D87884#2286918, @yubing wrote:

With avx512f, the cost SK_Select(v32i16 or v64i8) shoulde be 3(vmovdqa64 + vpternlogq)

The moves probably don't really count since they can be eliminated during register renaming. So only the vpternlog executes.

Eh, Craig, why it has relationship with register renaming? I thought, vternlog's third operand should be provided by a vmovdqa64.
Besides, we can observe the following asm for v32i16's SK_Select:

vmovdqa64       .LCPI0_0(%rip), %zmm0   # zmm0 = [0,0,0,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535,65535]
vpternlogq      $202, 144(%rbp), %zmm4, %zmm0

Sorry I thought the vmovdqa you mentioned was due to the vpternlogq reading 3 sources and clobbering one of them. So sometimes it needs a register to register move to preserve a register.

I'm not sure if we usually cost the constant pool load since its loop invariant. Do we cost the load that vpermi2b/w/d/q would use for 2 source permute?

In D87884#2286958, @craig.topper wrote:

In D87884#2286918, @yubing wrote:

With avx512f, the cost SK_Select(v32i16 or v64i8) shoulde be 3(vmovdqa64 + vpternlogq)

The moves probably don't really count since they can be eliminated during register renaming. So only the vpternlog executes.

With avx512f, the cost SK_Select(v32i16 or v64i8) shoulde be 3(vmovdqa64 + vpternlogq)

In D87884#2285420, @RKSimon wrote:

@yubing I've added shuffle-select.ll which should have better test coverage - please can you rebase and check?

Delete some testcases which was added previously since they are for Instruction::Select instead of Instruction::ShuffleVector(SK_Select)

Thanks for your comments, Simon. With your Comments, I found my new testcases are useless since they are for Instruction::Select instead of Instruction::ShuffleVector(SK_Select)

Just a rebase

https://reviews.llvm.org/B72136 shows it fails when making HTTP Request. But I don't have permission to restart the build procedure.
Besides, I've check-all locally with success.

Modify a testcase: clang/test/CodeGenCXX/float128-declarations.cpp

In D81791#2138692, @RKSimon wrote:

@yubing @pengfei @craig.topper Please can you confirm the regressions have now been addressed?

In D79987#2065821, @RKSimon wrote:

@yubing I think my fixes for PR45974 have addressed this now - please can you confirm?

In D80906#2065694, @craig.topper wrote:

Broadcast should only demand the lowest element. The recursive call to SimplifyDemandedVectorElts call is supposed to ignore the incoming DemandedElts if the SDValue has more than one use.

In D79987#2041642, @RKSimon wrote:

I'm still looking at fixing getFauxShuffleMask (PR45974) but that might take a while, so this sort of approach is probably necessary.

Did you investigate replacing getTargetShuffleInputs with getTargetShuffleAndZeroables in the SimplifyDemandedBitsForTargetNode/SimplifyDemandedVectorEltsForTargetNode?

PING @RKSimon

In D79987#2038738, @RKSimon wrote:

Really we need to stop creating nodes inside getFauxShuffle - I'm going to see if we can do this without too many regressions.

@RKSimon , you're right. After checking https://reviews.llvm.org/rL146415, I found the makefile has disable this testcase for i386.

Committed in https://github.com/llvm/llvm-test-suite/commit/16265f5a73211d7497e41af43e895eb230c13b89

In D67210#1659230, @RKSimon wrote:

Please abandon this, it isn't a valid solution to the issue (raised at PR43227). I have a WIP fix that will address this correctly.

I've submit a patch to solve the bug which I commented yesterday.
https://reviews.llvm.org/D67210

Hi, Simon. This patch has produced a bug in llvm: