If we query an AA with Attributor::getAAFor in AbstractAttribute::manifest, the AA may be updated.
This patch makes use of the phase flag in Attributor, and handle getAAFor behavior according to the flag.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Can you replace all uses of getAAFor in manifest by the new API in this patch?
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
979 | Should we call this "getAADuringManifest" or do we expect another place we use it? |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
979 | I will rename this getAADuringManifestFor. |
- rename getter getAADuringManifestFor
- replace some existing getAAFor in manifest with this
Some AAs use checkForAll... in manifest, and getAAFor is used in the function.
I think we need to add a new parameter like bool DuringManifest to them in a follow-up.
llvm/lib/Transforms/IPO/AttributorAttributes.cpp | ||
---|---|---|
3070 ↗ | (On Diff #288036) | Though I'm not sure why we force update and track dependence here, I think we can replace this with a new API. |
I think rather than creating a new api function, it would be more robust if we had a flag as member of the attributor.
It would be similar to SeedingPeriod flag that I have added.
Simply we would make it true in the Attributor::manifestAttributes function and then we would have a assertion in Attributor::updateAA
Thank you for the suggestion. I'm thinking about the same approach. I totally agree with @kuter. It is slightly hard for us to guarantee Attributor not to update AAs during manifestation by adding a new API.
Adding a flag that indicates which stage of the process (e.g. the update stage or the manifestation stage) we are in is better, I think.
@jdoerfert How do you think about this?
Yeah, I'm fine with a member flag. Though we should consider making the thing an enum now, like
enum { SEEDING, UPDATE, MANIFEST, } Phase;
or something like that. Once we have to juggle 2 booleans this might already by easier.
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
984 | Some AA uses the same helper function that contains getAndUpdateAAFor in both updateImpl and manifest. Therefore, we should ignore the enforcement in this case rather than abort. |
LGTM, without print, if you want the print we can talk about it.
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
984 |
That doesn't work because we need to specialize the template (I think). I'd go without a print for now. |
llvm/include/llvm/Transforms/IPO/Attributor.h | ||
---|---|---|
984 | I understand. I will delete debug print. |
Should we call this "getAADuringManifest" or do we expect another place we use it?