mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2024-12-04 09:45:00 +00:00
4e796fd7b6
This got reverted because a dependency was reverted. It has since been reapplied, so reapply this as well. ----- Related to D69686. As noted there, LVI currently behaves differently for integer and pointer values: For integers, the block value is always valid inside the basic block, while for pointers it is only valid at the end of the basic block. I believe the integer behavior is the correct one, and CVP relies on it via its getConstantRange() uses. The reason for the special pointer behavior is that LVI checks whether a pointer is dereferenced in a given basic block and marks it as non-null in that case. Of course, this information is valid only after the dereferencing instruction, or in conservative approximation, at the end of the block. This patch changes the treatment of dereferencability: Instead of including it inside the block value, we instead treat it as something similar to an assume (it essentially is a non-nullness assume) and incorporate this information in intersectAssumeOrGuardBlockValueConstantRange() if the context instruction is the terminator of the basic block. This happens either when determining an edge-value internally in LVI, or when a terminator was explicitly passed to getValueAt(). The latter case makes this more powerful than the previous implementation as a side-effect, and this does actually seem benefitial in practice. Of course, we do not want to recompute dereferencability on each intersectAssume call, so we need a new cache for this. The dereferencability analysis requires walking the entire basic block and computing underlying objects of all memory operands. This was previously done separately for each queried pointer value. In the new implementation (both because this makes the caching simpler, and because it is faster), I instead only walk the full BB once and cache all the dereferenced pointers. So the traversal is now performed only once per BB, instead of once per queried pointer value. I think the overall model now makes more sense than before, and there will be no more pitfalls due to differing integer/pointer behavior. Differential Revision: https://reviews.llvm.org/D69914 |
||
|---|---|---|
| .. | ||
| 2010-09-02-Trunc.ll | ||
| 2010-09-26-MergeConstantRange.ll | ||
| add.ll | ||
| alloca.ll | ||
| and.ll | ||
| ashr.ll | ||
| basic.ll | ||
| conflict.ll | ||
| crash.ll | ||
| deopt.ll | ||
| guards.ll | ||
| icmp.ll | ||
| merge-range-and-undef.ll | ||
| minmaxabs.ll | ||
| mul.ll | ||
| non-null.ll | ||
| overflow_predicate.ll | ||
| overflows.ll | ||
| phi-common-val.ll | ||
| pointer.ll | ||
| pr35807.ll | ||
| profmd.ll | ||
| range.ll | ||
| sdiv.ll | ||
| select.ll | ||
| sext.ll | ||
| shl.ll | ||
| srem.ll | ||
| sub.ll | ||
| udiv.ll | ||
| urem.ll | ||