[all-commits] [llvm/llvm-project] aca335: [ValueTracking] Let analyses assume a value cannot...

Juneyoung Lee via All-commits all-commits at lists.llvm.org
Wed Apr 22 16:09:12 PDT 2020


  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: aca335955c0dfe5dc783bf21e1d883c1aae33abc
      https://github.com/llvm/llvm-project/commit/aca335955c0dfe5dc783bf21e1d883c1aae33abc
  Author: Juneyoung Lee <aqjune at gmail.com>
  Date:   2020-04-23 (Thu, 23 Apr 2020)

  Changed paths:
    M llvm/include/llvm/Analysis/ValueTracking.h
    M llvm/lib/Analysis/ScalarEvolution.cpp
    M llvm/lib/Analysis/ValueTracking.cpp
    M llvm/lib/Transforms/Instrumentation/PoisonChecking.cpp
    M llvm/lib/Transforms/Scalar/IndVarSimplify.cpp
    M llvm/lib/Transforms/Scalar/SeparateConstOffsetFromGEP.cpp
    M llvm/test/Analysis/ScalarEvolution/flags-from-poison.ll

  Log Message:
  -----------
  [ValueTracking] Let analyses assume a value cannot be partially poison

Summary:
This is RFC for fixes in poison-related functions of ValueTracking.
These functions assume that a value can be poison bitwisely, but the semantics
of bitwise poison is not clear at the moment.
Allowing a value to have bitwise poison adds complexity to reasoning about
correctness of optimizations.

This patch makes the analysis functions simply assume that a value is
either fully poison or not, which has been used to understand the correctness
of a few previous optimizations.
The bitwise poison semantics seems to be only used by these functions as well.

In terms of implementation, using value-wise poison concept makes existing
functions do more precise analysis, which is what this patch contains.

Reviewers: spatel, lebedev.ri, jdoerfert, reames, nikic, nlopes, regehr

Reviewed By: nikic

Subscribers: fhahn, hiraditya, llvm-commits

Tags: #llvm

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




More information about the All-commits mailing list