This is an archive of the discontinued LLVM Phabricator instance.

DAGCombiner: Don't stop finding better chain on 2 aliases
ClosedPublic

Authored by arsenm on Oct 5 2015, 9:04 AM.

Details

Reviewers
hfinkel
Summary

The comment says this was stopped because it was unlikely to be
profitable. This is not true if you want to combine vector loads
with multiple components.

For a simple case that looks like

t0 = load t0 ...
t1 = load t0 ...
t2 = load t0 ...
t3 = load t0 ...

t4 = store t0:1, t0:1
  t5 = store t4, t1:0
    t6 = store t5, t2:0
      t7 = store t6, t3:0

We want to get all of these stores onto a chain
that is a TokenFactor of these N loads. This mostly
solves the AMDGPU merge-stores.ll regressions
with -combiner-alias-analysis for merging vector
stores of vector loads.

Diff Detail

Event Timeline

arsenm updated this revision to Diff 36523.Oct 5 2015, 9:04 AM
arsenm retitled this revision from to DAGCombiner: Don't stop finding better chain on 2 aliases.
arsenm updated this object.
arsenm added a reviewer: hfinkel.
arsenm added a subscriber: llvm-commits.
hfinkel accepted this revision.Oct 5 2015, 9:09 AM
hfinkel edited edge metadata.

LGTM.

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
14365

It would be nice, IMHO, to get rid of these hard-coded depth limits and turn them into cl::opts. This is a general comment, as I feel the same way about all of these depth limits everywhere. [I'm not requesting that you change this here].

This revision is now accepted and ready to land.Oct 5 2015, 9:09 AM
arsenm added inline comments.Oct 5 2015, 9:31 AM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
14365

I have a later patch that turns this into a TargetLowering preference. The depth limit is a problem if you want to find adjacent large vectors

arsenm closed this revision.Oct 12 2015, 5:51 PM

r250138 with some test changes since the x8 tests depend on a patch I've decided to submit later