This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG] Combine extload/store/load sequence into extload.
AcceptedPublic

Authored by ab on Dec 5 2014, 1:56 PM.

Details

Reviewers
qcolombet
Summary

If this extload is directly stored, and that store's input value was
loaded before still, try to avoid the roundtrip through memory and
extload directly from the original memory location.

This can't be caught by the other store-to-load forwarding DAGCombines,
because the extload's memory type might not be legal.
Instead, try to match this:

v4i32 load %ptr2, zext from v4i8
  store i32 %value, %ptr2
    %value = load i32 %ptr1

to turn the extload into:

v4i32 load %ptr1, zext from v4i8

Avoids a regression in an X86 testcase with D6533.

Diff Detail

Event Timeline

ab updated this revision to Diff 16997.Dec 5 2014, 1:56 PM
ab retitled this revision from to [SelectionDAG] Combine extload/store/load sequence into extload..
ab updated this object.
ab edited the test plan for this revision. (Show Details)
ab added a reviewer: qcolombet.
ab added a subscriber: Unknown Object (MLST).
qcolombet accepted this revision.Dec 8 2014, 2:38 PM
qcolombet edited edge metadata.

Hi Ahmed,

LGTM.

Thanks,
-Quentin

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
8314

IIRC, we tend to write the chain of computation in the opposite order:
load
store
extload

Please make sure you use the same convention here and I did not remember correctly, then ignore this :).

8317

!ISD::isNON_EXTLoad(N) => ISD::isEXTLoad(N)
That may be less contrived.

This revision is now accepted and ready to land.Dec 8 2014, 2:38 PM
ab added a comment.Jan 21 2015, 12:02 PM

Before committing, a few more questions, inline.

Thanks for the review!
-Ahmed

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
8314

You're right, I was corrupted by SDNode::dumpr() :P

8317

The name is misleading: isEXTLoad checks for "anyext-loads", not "any kind of extload"!

8323

Should we also check that the types are equivalent? For instance, if you have

%v = load float %p1
store float %v, %p2
%v2 = i64 load %p2, zext from i32

would it be a problem? (I don't think so, but I'm having second thoughts.)

8329

I think we can remove this check: we don't really care that the alignment is the same, do we? As long as the new load has the same alignment as the first (non-extending) one.

qcolombet added inline comments.Jan 22 2015, 11:32 AM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
8317

Right :).

8323

As long as we read the same number of bits, this is fine.
You already check for that :).

8329

Indeed, we do not need to check that the alignment is the same.

As long as the new load has the same alignment as the first (non-extending) one.

I do not think we need to check for that. Nevertheless, we should check that the alignment for the new load (derived from the load of %p1) is enough to be legal.

Does it make sense?