This is an archive of the discontinued LLVM Phabricator instance.

[DAG] Check for preexisting store when emiting stack convert
AbandonedPublic

Authored by niravd on Jan 3 2017, 11:50 AM.

Details

Reviewers
jyknight
bogner
Summary

Before creating a new store to do a cast, check if an existing store is viable
and can be used.

Event Timeline

niravd updated this revision to Diff 82925.Jan 3 2017, 11:50 AM
niravd retitled this revision from to [DAG] Check for preexisting store when emiting stack convert.
niravd added reviewers: jlebar, jyknight, bogner.
niravd updated this object.
niravd added a subscriber: llvm-commits.
jlebar edited edge metadata.Jan 3 2017, 2:49 PM

This seems sane to me, but I don't quite feel comfortable signing off on it.

lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
1664

see if we

1665

location. If so, use that.

1666

No need for a blank line here, since the comment applies just to the loop.

test/CodeGen/PowerPC/share-bitcast-stores.ll
4

a viable one

4

Please wrap to 80 chars.

jlebar removed a reviewer: jlebar.Jan 3 2017, 2:49 PM
jlebar added a subscriber: jlebar.
jyknight edited edge metadata.Jan 4 2017, 8:25 AM

Is it actually okay to introduce a read from a memory location that didn't have one in the source? This might do the wrong thing if e.g. if you have two threads non-atomically writing to a global, but never reading it. I'd suspect it's not okay, because it introduces a data race, but I'm not certain.

Going back to the case this is supposed to be improving, from ppc64-align-long-double.ll in the D14834 patch. In that case, there *was* a load, but it got eliminated as unnecessary, by forwarding the value through from the store, instead. So, by the time we realize that the bitcast needs to be lowered to store then load, that information is gone.

We could change this patch to only allow introducing new loads from a spill slot -- that might handle the particular thing noticed in the above test, and not have issues with potential for incorrectness. But that seems a somewhat small special case so I'm not sure it's actually worth it. I mean -- the calling lowering of that function is already bad, with seemingly-spurious storing of registers to memory in lowering the struct* byval argument, anyways.

I'm inclined to suggest just reverting this and leaving that test with its FIXME...

niravd abandoned this revision.Jan 30 2017, 7:03 AM