[LLVMbugs] [Bug 4393] New: Default AA used instead of supplied AA
bugzilla-daemon at cs.uiuc.edu
bugzilla-daemon at cs.uiuc.edu
Sun Jun 14 10:14:35 PDT 2009
http://llvm.org/bugs/show_bug.cgi?id=4393
Summary: Default AA used instead of supplied AA
Product: new-bugs
Version: unspecified
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: new bugs
AssignedTo: unassignedbugs at nondot.org
ReportedBy: edwintorok at gmail.com
CC: dpatel at apple.com, llvmbugs at cs.uiuc.edu
If a pass doesn't preserve AA (such as -simplify-cfg), then the passmanager
will remove the custom AA supplied on the commandline from AvailableAnalysis,
and thus the next time another pass needs AA (for example -gvn) it will
find the immutable basic AA as implementation.
The workaround is to manually rerun the custom AA after a pass that doesn't
preserve AA. This shouldn't be necessarry, the passmanager should remember
what the preferred implementation for an interface/analysisgroup is,
and rerun it if it was invalidated.
If I try to implement a custom AA as an immutablepass, then it is impossible to
use it, even if there is no other pass between -custom-aa and -gvn.
The reason is that the custom AA will get basicAA added as dependency (by the
the parent AliasAnalysis::getAnalysisUsage), and thus
ImmutablePasses will contain BasicAA, then my CustomAA
findAnalysis will thus find BasicAA as implementing AliasAnalysis, before my
pass, thus my pass is never chosen as implementing the interface.
The reason is that dependent analysis are added to various lists
(immutablepasses), before the analysis itself.
I think the passmanager shouldn't rely on the order analysis are added to
immutablepasses (since there is no way to add your own AA as first),
but instead use another Map that specifies the preferred implementation.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list