Take the following C function:
int getValue(int *array) {
int i = 0;
while (1) {
if (array[i]) {
break;
}
i++;
}
return array[i];
}
this compiles into the following RVSDG (after opt's SROA and jlm-opt's AAAndresenRegionAware, StoreValueForwarding and CNE):

The load of array[i] in region 1 could in theory be replaced by forwarding the load from inside the theta. Unlike #1672, this does not need any fancy predicate aware tracing. The only reason SVF is not currently performing the forwarding is that LocalAA is unable to confirm that the two loads have the same address. The loads take their addresses from separate GEPs. In other situations, NodePushOut + CNE helps unify common GEPs, making it trivial to see that the address is identical after all. NodePushOut is however not any help in this situation, due to the theta.
I see two "solutions" to this:
- Either there is some sort of "NodePullIn" flavor that sees that the SEXT and GEP are identical within the theta and after the theta, so the value inside the theta could instead be routed out.
- The LocalAA gains the ability to trace origins of GEP instructions, even when the origins can not be traced to actual compile time constants. (LLVM's BasicAA has this ability)
Take the following C function:
this compiles into the following RVSDG (after opt's SROA and jlm-opt's AAAndresenRegionAware, StoreValueForwarding and CNE):

The load of
array[i]in region 1 could in theory be replaced by forwarding the load from inside the theta. Unlike #1672, this does not need any fancy predicate aware tracing. The only reason SVF is not currently performing the forwarding is that LocalAA is unable to confirm that the two loads have the same address. The loads take their addresses from separate GEPs. In other situations, NodePushOut + CNE helps unify common GEPs, making it trivial to see that the address is identical after all. NodePushOut is however not any help in this situation, due to the theta.I see two "solutions" to this: