[all-commits] [llvm/llvm-project] 088577: [Delinerization] Require by offset to be zero.

[Michael Kruse via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 088577a38e603d3537816de1f2a249d598de8dd9
      https://github.com/llvm/llvm-project/commit/088577a38e603d3537816de1f2a249d598de8dd9
  Author: Michael Kruse <llvm-project at meinersbur.de>
  Date:   2021-09-08 (Wed, 08 Sep 2021)

  Changed paths:
    M llvm/lib/Analysis/Delinearization.cpp
    A llvm/test/Analysis/Delinearization/byte_offset.ll

  Log Message:
  -----------
  [Delinerization] Require by offset to be zero.

Users of delinearization assume that the the offset into the array element is zero. In most cases it will indeed be zero, but if it is not, the delinearization has to fail since it violates that assumption without the API even allowing to signal to the caller that the by offset is non-zero.

This bug caused Polly to miscompile blender (526.blender_r from SPEC CPU 2017) in -polly-process-unprofitable mode. The SCEV expression incorrectly delinearized has been reduced in the test case byte_offset.ll. The dropped offset into the array element of size 4 (a float) is ((sext i32 %mul7.i4534 to i64) + {(sext i32 %i1 to i64),+,((sext i32 (1 + ((1 + %shl.i.i) * (1 + %shl.i.i)) + %shl.i.i) to i64) * (sext i32 %i1 to i64))}<%for.body703>). This significant component was just dropped, and the wrong pointer was computed when regenerating code from the remaining delinearized subscripts. This occurred during blender's subsurface scattering implementation. As a result, blender's rendering diverged from the reference image.

Patch D108885 would also fix the API.

Reviewed By: bmahjour

Differential Revision: https://reviews.llvm.org/D109133