Thank you for your comments in the last call. I’d like to organize my idea and provide some examples.
The targets of this implementation are indicies as the input of ext_array_coor, not operations that ext_array_coor includes internally. In other words, the new pass for this would run before FIRToLLVMLowering pass.
The following is an example of codes and generated LLVM IR.
The addition generating %14 in LLVM IR can have nsw, and this implementation would add nsw to it.
As I said, I would introduce some constraints on the inputs of ext_array_coor. The following code is an example that shouldn’t have nsw. (It’s not a practical code, but it would be accepted.)
In the LLVM IR, the addition generating %34 can have nsw while the one generating %28 cannot because i+128 as signed integer might overflow. AFAIK, however, there is no way to confirm it at the moment. I suspect programmers don’t recognize that OUT_OF_RANGE has a code which can overflow. Therefore, I conservatively think all operations in this index calulation should have no nsw even though index overflow is non-conforming.
This implementation would accept only the following index patterns. (a is an array, m and n are constants, and i is a variable.)
a(m*i)a(i+n)a(m*i+n)
As you know, however, this idea has an obvious defect. It ignores many patterns which can have nsw actually. (e.g. a((m+i)*n)) I started with the above conditions to make the implementation as simple as possible.