[PATCH] Remove redundant canonicalization rules from method DAGCombiner::visitVECTOR_SHUFFLE.

Andrea Di Biagio andrea.dibiagio at gmail.com
Wed Aug 13 03:15:23 PDT 2014


Forget about this patch...
I have just realized that It would be an error to remove those
canonicalization rules from the DAGCombiner.
Calls to method 'ReplaceAllUsesWith' may potentially break the
canonical form of a shuffle; this can happen for example if an undef
is propagated to the first operand of a shuffle node. That's why we
still have to canonicalize shuffles within method
'DAGCombiner::visitVECTOR_SHUFFLE'.

Sorry for the wrong patch.
-Andrea

On Tue, Aug 12, 2014 at 7:07 PM, Andrea Di Biagio
<andrea.dibiagio at gmail.com> wrote:
> Hi,
>
> Target independent shuffle dag nodes are only created by the backend
> using method 'SelectionDAG::getVectorShuffle'. Currently, ff we try to
> use the overloaded method 'getNode' that takes as input three
> SDValues, the compiler would eventually hit a
> `llvm_unreachable("should use getVectorShuffle constructor!")`. That
> suggests that the only possible/safe way to create ISD shuffles is
> through method 'getVectorShuffle'.
>
> Method 'SelectionDAG::getVectorShuffle' knows how to perform some
> basic simplifications in order to always emit a "canonical" dag node.
> For example, it knows how to canonicalize a shuffle according to
> rules:
>   // Canonicalize shuffle undef, undef -> undef
>   // Canonicalize shuffle v, v -> v, undef
>   // Canonicalize shuffle undef, v -> shuffle v, undef
>
> Those same rules are currently duplicated within method
> 'DAGCombiner::visitVECTOR_SHUFFLE'. If my previous reasoning is
> correct, then those rules are "dead" (i.e. we never trigger those
> rules from the DAGCombiner).
> Therefore, it should be safe to remove the redundant canonicalization
> rules from visitVECTOR_SHUFFLE.
>
> This patch simplifies the code in method
> 'DAGCombiner::visitVECTOR_SHUFFLE' removing the above-mentioned "dead"
> canonicalization rules.
> No functional change intended.
>
> Please let me know if this is ok to submit.
>
> Thanks,
> Andrea



More information about the llvm-commits mailing list