This is an archive of the discontinued LLVM Phabricator instance.

[WinEHPrepare] Fix catchret successor phi demotion
ClosedPublic

Authored by JosephTremoulet on Aug 16 2015, 11:15 AM.

Details

Summary

When demoting an SSA value that has a use on a phi and one of the phi's
predecessors terminates with catchret, the edge needs to be split and the
load inserted in the new block, else we'll still have a cross-funclet SSA
value.

Add a test for this, and for the similar case where a def to be spilled is
on and invoke and a critical edge, which was already implemented but
missing a test.

Diff Detail

Event Timeline

JosephTremoulet retitled this revision from to [WinEHPrepare] Fix catchret successor phi demotion.
JosephTremoulet updated this object.
JosephTremoulet added a reviewer: majnemer.
JosephTremoulet added a subscriber: llvm-commits.
majnemer accepted this revision.Aug 16 2015, 12:50 PM
majnemer edited edge metadata.

Nice catch, LGTM.

As an aside, would it be more optimal (and legal) to have a single slot for the value contained within %phi? We'd still need two stores but I think we could save a load. If so, we might want a TODO for it if we don't already have an appropriate one elsewhere.

This revision is now accepted and ready to land.Aug 16 2015, 12:50 PM

If I'm understanding correctly, you're suggesting that we could use the same slot to demote %x that we use to demote %y, and then instead of inserting loads in each predecessor of %join (which requires splitting edges) we could just insert a load at the top of %join? I do think that's legal, and by static count it eliminates a load but by dynamic count it doesn't. I think what we could do to get cases like this is check to see if any to values we're demoting appear as arguments to the same phi and have non-interfering liveranges, and if so coalesce their spill slots and (split predecessors of the phi if it has incoming values we're not demoting and) insert a single load after the join rather than one load per pred. No, the TODOs already in the code don't cover that, LMK if you think it's worth adding one (or if I've misunderstood what you're suggesting).

No, the TODOs already in the code don't cover that, LMK if you think it's worth adding one (or if I've misunderstood what you're suggesting).

Nah, I think it's fine to proceed.