This is an archive of the discontinued LLVM Phabricator instance.

Extracting a splat value from vector
ClosedPublic

Authored by delena on Jul 12 2015, 7:05 AM.

Details

Summary

We have the following interface in IRBuilder.h:
Value *CreateVectorSplat( unsigned NumElts , Value * V , const Twine & Name = "" ) { ..}

This function creates 2 instructions - “insertelement” and “shuffle” with all-zero mask.

Now I'm adding
Value *getSplatValue(Value *Val)

This function recognizes the pattern - insertelement+shuffle and returns the splat value (or nullptr).
It also returns a splat value form ConstantDataVector, for completeness.

( I don't know why functions in this file are not wrapped with "namespace llvm")

Diff Detail

Repository
rL LLVM

Event Timeline

delena updated this revision to Diff 29522.Jul 12 2015, 7:05 AM
delena retitled this revision from to Extracting a splat value from vector.
delena updated this object.
delena added reviewers: hfinkel, dblaikie.
delena set the repository for this revision to rL LLVM.
delena added a subscriber: llvm-commits.

Probably best to commit this with a use of it... otherwise this is just dead code.

delena updated this revision to Diff 29563.Jul 13 2015, 7:12 AM

I use the new getSplatValue() interface in DAG building.

hfinkel added inline comments.Jul 25 2015, 5:15 PM
lib/Analysis/VectorUtils.cpp
419

Does this handle the case where some of the mask entries are undef?

delena updated this revision to Diff 30650.Jul 26 2015, 2:09 AM
delena marked an inline comment as done.

Addressed Hal's comments: added more verification for shuffle mask - zero or undef.
Added index verification for InsertElement instruction.

hfinkel accepted this revision.Jul 26 2015, 4:43 AM
hfinkel edited edge metadata.

This LGTM. Please either commit this with a test case covering the masks with undef (and the insertelement index verification), or add such a test case to D11121 before you commit.

lib/Analysis/VectorUtils.cpp
428

fisrt -> first

lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
3092

I'd highly prefer that Gep were GEP, GepPtrs -> GEPPtrs, etc. to match our general naming convention. But that should be done in a separate commit regardless.

This revision is now accepted and ready to land.Jul 26 2015, 4:43 AM
This revision was automatically updated to reflect the committed changes.