[PATCH] D147078: [LICM][BPF] Disable hoistMinMax() optimization for BPF target

[Yonghong Song via Phabricator via llvm-commits]

yonghong-song created this revision.
yonghong-song added reviewers: ast, mkazantsev, nikic, chandlerc.
Herald added subscribers: StephenFan, asbirlea, hiraditya.
Herald added a project: All.
yonghong-song requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Recently, we hit a bpf verification failure due to llvm17 patch ([1])

  6b03ce374e0d  [LICM] Simplify (X < A && X < B) into (X < MIN(A, B)) if MIN(A, B) is loop-invariant

The current bpf verifier is not able to handle newly-generated code pattern.
Alexei pushed a workaround ([2]) to temporarily fix the issue.

There are multiple ways to fix the regression:
 (1). fix the issue in llvm,
 (2). improve bpf verifier to handle new code patterns.

Although we could improve verifier for this case, but if users use llvm17 for
old kernels, the problem still exists. So ideally the issue should be fixed
in llvm.

There are a few options we can fix the issue in llvm:

  (a). In the past, we have tried to add passes in llvm to prevent/undo certain
       optimization to please the verifier. For example, Patch [3] tries to add
       some bpf specific builtin's to prevent some code transformation by pattern
       matching certain code patterns. 
  (b). Disable particular optimization.

There is a drawback with pattern matching approach (a) where bpf backend
needs to add new 'undo' or 'prevention' logic in llvm if pattern changes
or new optimization emerges like in [1].

Another approach is to disable particular optimization. We have tried
before with [4] and utimately we introduced [3] to workaround the issue.
As I mentioned in the above, maybe we can simply disable particular
optimization instead of pattern matching. There are two approaches
to disable a particular optimization.

  (i).  Add some hooks in TargetTransformInfo to disable a particular
        optimization. There are two ways to do this. One is to have
        a generic callback isBPFTarget(), and the other is to have
        optimization specific hooks.
  (ii). Construct a BPF specific ModulePassManager.

This patch added a new TargetTransformInfo callback isBPFTarget() where
if a new optimization generates code patterns where bpf verifier could
not handle easily, it can be simply disabled for BPF backend.

  [1] https://reviews.llvm.org/D143726
  [2] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit?id=3c2611bac08a834697be918ac357eaff2e47d5b3
  [3] https://reviews.llvm.org/D85570
  [4] https://reviews.llvm.org/D81859


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D147078

Files:
  llvm/include/llvm/Analysis/TargetTransformInfo.h
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Analysis/TargetTransformInfo.cpp
  llvm/lib/Target/BPF/BPFTargetTransformInfo.h
  llvm/lib/Transforms/Scalar/LICM.cpp
  llvm/test/CodeGen/BPF/licm-maxmin.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D147078.509116.patch
Type: text/x-patch
Size: 8894 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20230328/60569380/attachment.bin>