[PATCH] D36454: [X86] Changes to extract Horizontal addition operation for AVX-512.
Jatin Bhateja via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Sep 6 00:43:21 PDT 2017
jbhateja added a comment.
In https://reviews.llvm.org/D36454#861826, @craig.topper wrote:
> I think we should try to combine based on the add only being used by the extract_vector_elt. Turn the add into a 128-bit add being fed by extract_subvectors. Similarly if we see an add only being used by an extract_subvector we can shrink that add too and push the extracts up. This type of transform feels more generally useful because it will allow us to narrow many more adds in this code. This will enable EVEX->VEX to use a smaller encoding. We can apply this to many other opcodes as well.
>
> If we do this early enough we should be able to shrink the add before the horizontal add detection.
Two cases for DAG node reduction:-
1/ Look at operands and try squeezing them up (EXTRACT_SUBVECTOR) for narrower operation which is then concatinated with a pad to make the final result size same as original. Here we only look at the operands and not the uses of the operation. Which means it could break valid patterns being checked at the use nodes due to insertion of CONCAT_VECTORS now.
b/ Look at both the uses of the DAG node along with the operands of the node while narrowing down the operation. Idea here is to avoid insertion of extra concat operation for padding which shall keep the pattern matches at use node happy.
My initial patch was based on strategy (b), What I get from you above comment is to change it for any generic OPCODE instead of HADD. Correct?
https://reviews.llvm.org/D36454
More information about the llvm-commits
mailing list