This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Avoid combining the bitcast of a var that is used as both address and result of the same load instruction
AcceptedPublic

Authored by Carrot on May 11 2016, 9:25 AM.

Details

Reviewers
majnemer
Summary

This patch fixes https://llvm.org/bugs/show_bug.cgi?id=27703.

In the testcase, the result of a load instruction is used as the address of the same instruction, so a bitcast is necessary to change the value type to address type, we should avoid to optimize out the bitcast.

Diff Detail

Event Timeline

Carrot updated this revision to Diff 56927.May 11 2016, 9:25 AM
Carrot retitled this revision from to [InstCombine] Avoid combining the bitcast of a var that is used as both address and result of the same load instruction.
Carrot updated this object.
Carrot added a reviewer: majnemer.
Carrot added a subscriber: llvm-commits.
majnemer edited edge metadata.May 11 2016, 9:31 AM
majnemer added a subscriber: majnemer.

Please add a testcase.

Carrot updated this revision to Diff 56933.May 11 2016, 10:06 AM
Carrot edited edge metadata.

Testcase added.

Can add more context to this diff?

test/Transforms/InstCombine/pr27703.ll
2

please pipe this into FileCheck.

Carrot updated this revision to Diff 56940.May 11 2016, 10:54 AM
Carrot marked an inline comment as done.

Add more contents.

majnemer accepted this revision.May 11 2016, 11:01 AM
majnemer edited edge metadata.

LGTM with nits addressed.

test/Transforms/InstCombine/pr27703.ll
16

Can you check the load and the phi too?

This revision is now accepted and ready to land.May 11 2016, 11:01 AM
Carrot updated this revision to Diff 56943.May 11 2016, 11:27 AM
Carrot edited edge metadata.
Carrot marked an inline comment as done.
Carrot updated this revision to Diff 56976.May 11 2016, 4:12 PM

The original patch considers only one load instruction. There may be multiple load instructions, each loaded value is used as address of later load instruction, just as Caroline's testcase, it still causes problem. This updated patch solves the problem. Detecting the exact pattern is too complex. For simplicity the code gives up if the load address comes from another load instruction.

Please review it again.

Looks like patch was not committed.