[PATCH] D49280: [X86] Remove isel patterns for MOVSS/MOVSD ISD opcodes with integer types.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jul 13 08:56:49 PDT 2018


craig.topper added a comment.

The domain switching isn't really intentiional. The code I removed from X86ISelLowering was removing some bitcasts that made this optimize better.

What used to happen is this
-Lowering selects an fp typed MOVSS/MOVSD for the first shuffle and a PSHUFD for the second shuffle. The MOVSS/SD has bitcasts int->fp before it and a bitcast fp->int after it.
-Combining sees the MOVSS/SD and the bitcasts int->fp and turns into an integer MOVSS/MOVSD ISD node. This removes the bitcasts before and after it.
-Combining sees the PSHUFD producer has integer type and does nothing to chang it.

What happens now is
-Lowering selects an fp typed MOVSS/MOVSD for the first shuffle and a PSHUFD for the second shuffle. The MOVSS/SD has bitcasts int->fp before it and a bitcast fp->int after it.
-Combining sees the MOVSS/SD and the bitcasts int->fp, but does nothing to change it.
-Combining sees the PSHUFD, looks through the fp->int bitcast and finds the FP typed MOVSS/SD. Decides to rewrite the PSHUFD to SHUFPS to remove the fp->int bitcast, but ends up creating a new fp->int bitcast after the SHUFPS. The subsequent shuffles are on v8i16 type and so can't be fixed so the fp->int bitcast after the SHUFPS stays.

I don't have perf numbers. Based on the changes I think we're just moving the domain crossing one instruction later. And we picked up a move. The move is probably more costly on older CPUs that don't have move elimination.

I'm hoping there's somethign we can do in DAG combine to fix this. Maybe recognize the bitcast+shufps from fp->int and change it to pshufd+bitcast? Need to be careful to avoid an infinite loop with teh combine that turns pshud+bitcast into bitcast+shufps


Repository:
  rL LLVM

https://reviews.llvm.org/D49280





More information about the llvm-commits mailing list