Please use GitHub pull requests for new patches. Phabricator shutdown timeline

Use the new 'InvariantInfo' property to eliminate redundant loads with --instcombine
Needs ReviewPublic
Actions

Authored by lvoufo on Oct 22 2015, 9:12 PM.

Details

Reviewers

• dberlin
nlewycky

Summary

Similar to GVN in D14004: While processing instructions in InstCombine, mark global variables and alloca instructions corresponding to each encountered invariant intrinsic call as indicating 'writeonce' memory locations that either have been written into or can be written into again (once). Then, while scanning instructions backwards looking for available loads for a given memory location, be sure to temporarily disable or reset the markings, as appropriate.

This patch is a break-down of (corrected) D13606.

Diff Detail

Event Timeline

lvoufo updated this revision to Diff 38205.Oct 22 2015, 9:12 PM

lvoufo retitled this revision from to Use the new 'InvariantInfo' property to eliminate redundant loads with --instcombine.

lvoufo updated this object.

lvoufo added reviewers: nlewycky, reames, • dberlin.

lvoufo added a parent revision: D14003: Express and handle specific info about the processing of invariant intrinsics.

lvoufo added a subscriber: llvm-commits.

lvoufo mentioned this in D14006: Add a test case for --gvn and --instcombine extended with load elimination based on new 'InvarantInfo' property..Oct 22 2015, 9:17 PM

lvoufo mentioned this in D14007: Load elimination based on new 'InvarantInfo' property for global variables..Oct 22 2015, 9:25 PM

lvoufo mentioned this in D13606: [Introduction] Redundant load reduction with invariant intrinsics.Oct 22 2015, 9:35 PM

lvoufo added a child revision: D14006: Add a test case for --gvn and --instcombine extended with load elimination based on new 'InvarantInfo' property..

lvoufo mentioned this in D13619: [Extension] Optimizing const member objects..Oct 23 2015, 3:30 PM

Patch needs testcases.

lib/Transforms/InstCombine/InstructionCombining.cpp
1961	Why bother? We're guaranteed to visit the invariant.start and the invariant.end, right? Just handle invariant_start by replacing it with an undef, and let the generic "EraseInstFromFunction" call (below on line 1975) handle the invariant.end? I think the other case is an invariant applying to a bitcast instead of to the original object. Does this function work in that case? (Does it even pass isAllocSiteRemovable?)