This is an archive of the discontinued LLVM Phabricator instance.

DAGCombiner: Combine extract_vector_elt from build_vector
ClosedPublic

Authored by arsenm on Oct 12 2015, 8:12 AM.

Details

Reviewers
RKSimon
Summary

This basic combine was surprisingly missing.
AMDGPU legalizes many operations in terms of 32-bit vector components,
so not doing this results in many extra copies and subregister extracts
that need to be cleaned up later.

InstCombine already does this for the hasOneUse case. The target hook
is to fix a handful of tests which break (e.g. ARM/vmov.ll) which turn
from a vector materialize repeated immediate instruction to a constant
vector load with more scalar copies from it.

I think the isTypeLegal check should be !LegalTypes ||| isLegalType((), but there
seems to be an intentionally added bug in getConstant where a build_vector with
mismatched type and element type, so on x86 an i1 vector type is the result type
of a build_vector with i8 input elements.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 37114.Oct 12 2015, 8:12 AM
arsenm retitled this revision from to DAGCombiner: Combine extract_vector_elt from build_vector.
arsenm updated this object.
arsenm added a subscriber: llvm-commits.
RKSimon added a subscriber: RKSimon.

Very surprising that this was missing!

include/llvm/Target/TargetLowering.h
1723

By 'use' do you just mean 'directly access' or do you foresee other possibilities?

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
11896

You may need to confirm that the operand value type is the same as the BUILD_VECTOR scalar value type - implicit truncation may be occurring.

arsenm added inline comments.Oct 12 2015, 2:36 PM
include/llvm/Target/TargetLowering.h
1723

Yes, directly access the input value. I had a hard time picking a name for this. Other options are something like isExtractVectorEltAsCheapAsScalarCopy

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
11896

Is this really supposed to be allowed? I would consider mismatched vector element and destination vector types to be a bug. The comment in getConstant made me very unhappy

arsenm added inline comments.Oct 12 2015, 2:39 PM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
11896

I also think this might be redundant with isTypeLegal on the element type. If this case is really allowed, I think it only happens if the scalar type is not legal and the vector is

RKSimon added inline comments.Oct 12 2015, 3:06 PM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
11896

Yes implicit truncation is permitted, a lot of the vector constant folding code has to deal with this.

Integer scalar input bit widths can be larger than the vector type, although all the scalars must have the same type. Both types can be legal so the isTypeLegal() test isn't enough.

You should be able to fold any constant truncation for free, but otherwise you will need a isTruncateFree test.

arsenm updated this revision to Diff 37197.Oct 12 2015, 4:34 PM

Make sure element type matches. Leave truncating if free out because I have so far failed to find an example where this happens

RKSimon accepted this revision.Oct 12 2015, 4:43 PM
RKSimon edited edge metadata.

LGTM

BTW - I ended up having to fix implicit truncation support for unary constant folding in rL236308 - I believe it was originally found through testing with llvm-stress.

This revision is now accepted and ready to land.Oct 12 2015, 4:43 PM
arsenm closed this revision.Oct 12 2015, 5:01 PM

r250129