[PATCH] D60890: [AArch64] splat before (f)mul to allow mul-by-element isel

Eli Friedman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Apr 18 16:45:58 PDT 2019


efriedma added a comment.

> The constant cases look better, but I'm not sure if this is a win if both operands are variables.

The key really isn't whether one of the operands is a constant; it's whether the operand is free or cheap to splat.  Constants are usually free to splat.  A splat is free to splat... although I guess that's unlikely to come up in practice given other optimizations.  A load is cheap to splat (the addressing mode for ld1r is very limited, so you're likely adding an extra instruction for address computation).  A loop-invariant operand is likely cheap to splat, but I don't think there's any way to handle that in SelectionDAG at the moment.  And of course, a multiply with an operand that's free to splat is itself free to splat, recursively.  Probably worth adding a testcase with more than one multiply.

For two arbitrary variables, it's basically neutral, like you've noted; splatting an operand has the same cost as splatting a result.

It's worth noting that at least on some chips, 128-bit multiplies have half the throughput of scalar and 64-bit vector multiplies.  But I don't think that directly affects this patch; you probably wouldn't want to add extra instructions just to make a multiply smaller.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D60890/new/

https://reviews.llvm.org/D60890





More information about the llvm-commits mailing list