This is an archive of the discontinued LLVM Phabricator instance.

[MemorySSA] Don't treat lifetime.end as NoAlias
ClosedPublic

Authored by nikic on Jan 31 2021, 9:06 AM.

Details

Summary

MemorySSA currently treats lifetime.end intrinsics as not aliasing anything. This breaks MemorySSA-based MemCpyOpt, because we'll happily move a read of a pointer below a lifetime.end intrinsic, as no clobber is reported.

I think the MemorySSA modelling here isn't correct. lifetime.end(p) has approximately the same effect as doing a memcpy(p, undef), and should be treated as a clobber.

This patch removes the special handling of lifetime.end, leaving alias analysis to handle it appropriately.

Diff Detail

Event Timeline

nikic created this revision.Jan 31 2021, 9:06 AM
nikic requested review of this revision.Jan 31 2021, 9:06 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2021, 9:06 AM

I think this makes sense on a high level, but I am not sure about the exact reason for the current handling. Perhaps @asbirlea or @george.burgess.iv have more context on this?

I'm not familiar with the original reasoning, so here are some thoughts.

The test that's updated doesn't make sense to me as it was done originally. The load access for P after a lifetime.end is strange.

Where I'd see this being useful is in loop optimizations, for temporaries declared inside a loop. Going around the loop to determine if an access can be hoisted/sunk, would need to bypass the lifetime marker, otherwise the clobbering access would remain the phi. But then any loop transformation using this information to take the access out of the loop, would need to also consider the lifetime markers found inside the loop and move or remove them. It's possible this is already happening right now and the lifetime markers are removed as being dead code, and that's why we haven't encountered the issue.
So, while I think MSSA's special handling on its own makes sense, I don't think any transformation currently uses this in a proper way.

I'm running some testing to check if this impacts optimizations in a meaningful way.

asbirlea accepted this revision.Feb 3 2021, 4:47 PM

This looks good!

This revision is now accepted and ready to land.Feb 3 2021, 4:47 PM
This revision was landed with ongoing or failed builds.Feb 4 2021, 12:10 PM
This revision was automatically updated to reflect the committed changes.