[all-commits] [llvm/llvm-project] 073777: [LVI][CVP] Add test for miscompilation by CVP due ...

Dmitry Makogon via All-commits all-commits at lists.llvm.org
Fri Feb 10 02:08:51 PST 2023

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 0737770c3e1d5e119148351610c39fb2483c7011
  Author: Dmitry Makogon <d.makogon at g.nsu.ru>
  Date:   2023-02-10 (Fri, 10 Feb 2023)

  Changed paths:
    A llvm/test/Analysis/LazyValueAnalysis/pr60629.ll

  Log Message:
  [LVI][CVP] Add test for miscompilation by CVP due to incorrect range returned by LVI

This adds a test case from PR60629 which shows a miscompilation by CVP.

  Commit: c77c186a647b385c291ddabecd70a2b4f84ae342
  Author: Dmitry Makogon <d.makogon at g.nsu.ru>
  Date:   2023-02-10 (Fri, 10 Feb 2023)

  Changed paths:
    M llvm/lib/Analysis/LazyValueInfo.cpp
    M llvm/test/Analysis/LazyValueAnalysis/pr60629.ll
    M llvm/test/Transforms/CorrelatedValuePropagation/cond-at-use.ll

  Log Message:
  [LVI] Don't traverse uses when calculating range at use

This effectively reverts 5c38c6a and 4f772b0.

A recently introduced LazyValueInfo::getConstantRangeAtUse returns incorrect
ranges for values in certain cases. One such example is described in PR60629.
The issue has something to do with traversing PHI uses of a value transitively.
As nikic pointed out, we're effectively reasoning about values from different
loop iterations.

In the faulting test case, CVP made a miscompilation because the calculated
range for a shift argument was incorrect. It returned empty-set, however it is
clearly not a dead code. CVP then erased the shift instruction because
of empty range.

Compare: https://github.com/llvm/llvm-project/compare/d768bf994f50...c77c186a647b

More information about the All-commits mailing list