This is an archive of the discontinued LLVM Phabricator instance.

[PATCH 14/27] [noalias] ScopedNoAliasAA: use C99 restrict rules for deducing noalias
Needs ReviewPublic

Authored by jeroen.dobbelaere on Oct 4 2019, 2:59 PM.

Details

Summary

This is part of the series started by D68484.

Look at {p.addr, p.objId, p.scope} for deducing noalias, making use
of recursive calls to AA to proof that p.addr is not aliasing.

This now works with the legacy and new pass manager.

Note: this is a stable point and tests should run fine with the patches applied up to this point.
Note: D68506 has been incorporated.

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptOct 4 2019, 3:00 PM
jeroen.dobbelaere edited the summary of this revision. (Show Details)

Thanks to Chandler for pointing out on how to get the recursive calls working with the new pass manager.
I also improved one testcase to really make sure that the full alias analysis chain is used, and not just the ScopedNoAliasAA part.

jeroen.dobbelaere retitled this revision from [PATCH 24/38] [noalias] ScopedNoAliasAA: use C99 restrict rules for deducing noalias to [PATCH 14/26] [noalias] ScopedNoAliasAA: use C99 restrict rules for deducing noalias.
jeroen.dobbelaere edited the summary of this revision. (Show Details)
jeroen.dobbelaere retitled this revision from [PATCH 14/26] [noalias] ScopedNoAliasAA: use C99 restrict rules for deducing noalias to [PATCH 14/27] [noalias] ScopedNoAliasAA: use C99 restrict rules for deducing noalias.

Rebased to 9fb46a452d4e5666828c95610ceac8dcd9e4ce16 (September 7, 2020)

Fixes an issue with the new pass manager: when the DominatorTreeAnalysis is invalidated, this analysis must also be invalidated.

Is unboundness (depth=0) of getUnderlyingObject() needed for correctness?