Page MenuHomePhabricator

[X86] Fold (and (or (xor X, -1), Y), Z) -> PTERNLOG Z, Y, X, 0xD0
AbandonedPublic

Authored by pengfei on Sep 4 2021, 6:53 AM.

Diff Detail

Event Timeline

pengfei created this revision.Sep 4 2021, 6:53 AM
pengfei requested review of this revision.Sep 4 2021, 6:53 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 4 2021, 6:53 AM

We do most TERNLOG matching inside X86DAGToDAGISel::tryVPTERNLOG (which has a 'FIXME: Handle inverted inputs?' comment) - might it be possible to handle this there?

We do most TERNLOG matching inside X86DAGToDAGISel::tryVPTERNLOG (which has a 'FIXME: Handle inverted inputs?' comment) - might it be possible to handle this there?

As far as I learnt it, it's hard to do so. We have 3 difficulties:

  1. We need a new ORNP node for pre-processing and the logic in tryVPTERNLOG, but ORNP isn't a canonical node like AND, ANDNP etc. that can be used for permutation;
  2. Even we have a ORNP, we have to change the logic to prioritise ORNP over other nodes and ignore the permutation math;
  3. Even we achieved 1 and 2, we have to change matchVPTERNLOG, because it assumes the operands are commutable while it's not true for this combine;

We do most TERNLOG matching inside X86DAGToDAGISel::tryVPTERNLOG (which has a 'FIXME: Handle inverted inputs?' comment) - might it be possible to handle this there?

As far as I learnt it, it's hard to do so. We have 3 difficulties:

  1. We need a new ORNP node for pre-processing and the logic in tryVPTERNLOG, but ORNP isn't a canonical node like AND, ANDNP etc. that can be used for permutation;
  2. Even we have a ORNP, we have to change the logic to prioritise ORNP over other nodes and ignore the permutation math;
  3. Even we achieved 1 and 2, we have to change matchVPTERNLOG, because it assumes the operands are commutable while it's not true for this combine;

In matchVPTERNLOG, why can’t we just check if each input is a single use xor with -1 after calculating the immediate and then change then change the mask appropriately. No new nodes needed

We do most TERNLOG matching inside X86DAGToDAGISel::tryVPTERNLOG (which has a 'FIXME: Handle inverted inputs?' comment) - might it be possible to handle this there?

As far as I learnt it, it's hard to do so. We have 3 difficulties:

  1. We need a new ORNP node for pre-processing and the logic in tryVPTERNLOG, but ORNP isn't a canonical node like AND, ANDNP etc. that can be used for permutation;
  2. Even we have a ORNP, we have to change the logic to prioritise ORNP over other nodes and ignore the permutation math;
  3. Even we achieved 1 and 2, we have to change matchVPTERNLOG, because it assumes the operands are commutable while it's not true for this combine;

In matchVPTERNLOG, why can’t we just check if each input is a single use xor with -1 after calculating the immediate and then change then change the mask appropriately. No new nodes needed

Sorry it should probably be in tryVPTERNLOG.

I posted an improvement to tryVPTERNLOG here D109295. This handles the basic case but doesn't peek through bitcasts or push broadcast through a not. Are those cases important for what you're trying to do here? I don't see any tests for them.

pengfei abandoned this revision.Sep 6 2021, 5:51 AM

I posted an improvement to tryVPTERNLOG here D109295. This handles the basic case but doesn't peek through bitcasts or push broadcast through a not. Are those cases important for what you're trying to do here? I don't see any tests for them.

No, thanks.