This patch makes uses of the context bridges introduced in D83299 to make
AAValueConstantRange call site specific.
I inspected the output that opt generates and it makes sense.
also the script's output (included in the patch) also makes sense the.
I will double check everything but this is weird.
File check fails to match the first check line.
Some minor comments below.
Upload diffs with full context please.
Can we split this in two statements for readability. Also use a C++ cast please. I think we can actually do cast on the AA and then getState() should give the right type. We might need to adjust the state wrapper return type though. Hope this makes some sense.
|2 ↗||(On Diff #278199)|
we should do this for the old and new PM, as well as the module and CGSCC pass.
LGTM with some comments to be addressed. This is cool :)
Nit: an 'argument'
This should not happen, right? Make it an assert instead.
We don't want the value here, do we. We want
const auto &AA = A.getAAFor<AAType>(QueryingAttribute, IRPosition::callsite_argument(*CBContext, ArgNo));
which might be better than the plain value result as it has a context instruction (and the attached attributes).
Use cast<..> and keep it as reference.
Split cb_range.ll into two files cb_range_enabled.ll and cb_range_disabled.ll.
This is needed because the combination of prefixes we use triggers a edge case with the
For more information see D95794 which tries to solve the issue (it doesn't work).
I don't think there is any non O(N!) to fix this edge case.
@kuter This is breaking some EXPENSIVE_CHECKS builds such as http://lab.llvm.org:8011/#/builders/16/builds/7624
AbstractAttribute isn't defined until later in the header - oddly my MSVC build is quite happy (after my fix at rGe74d6269259e28225a494ce98bd1762cdac1fe89)
Thanks , I am aware of this. CMake decided to rebuild everything after I did a git pull.
I just assumed that enabling assertions also enabled the expansive checks, I am sorry.