aliasGEP() currently implements some special handling for the case where all variable offsets are positive, in which case the constant offset can be taken as the minimal offset. However, it does not perform the same handling for the all-negative case. This means that the alias-analysis result between two GEPs is asymmetric: If GEP1 - GEP2 is all-positive, then GEP2 - GEP1 is all-negative, and the first will result in NoAlias, while the second will result in MayAlias.
Apart from producing sub-optimal results for one order, this also violates our caching assumption. In particular, if BatchAA is used, the cached result depends on the order of the GEPs in the first query. This results in an inconsistency in BatchAA and AA results, which is how I noticed this issue.
This assertion currently fails on Analysis/BasicAA/zext.ll.
Arguably this should be asserted in AA itself, but a) I'm not confident enough that this is the only asymmetry that exists right now and b) a more general assertion would have to be behind EXPENSIVE_CHECKS, so I figured this would be a good place to verify this initially.