[all-commits] [llvm/llvm-project] 8f28e8: [BPF] support for BPF_ST instruction in codegen

[eddyz87 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 8f28e8069c4ba1110daee8bddc4d5049b6d4646e
      https://github.com/llvm/llvm-project/commit/8f28e8069c4ba1110daee8bddc4d5049b6d4646e
  Author: Eduard Zingerman <eddyz87 at gmail.com>
  Date:   2023-08-16 (Wed, 16 Aug 2023)

  Changed paths:
    M llvm/lib/Target/BPF/BPFInstrInfo.td
    M llvm/lib/Target/BPF/BPFMISimplifyPatchable.cpp
    M llvm/lib/Target/BPF/BPFSubtarget.cpp
    M llvm/lib/Target/BPF/BPFSubtarget.h
    A llvm/test/CodeGen/BPF/CORE/field-reloc-st-imm.ll
    A llvm/test/CodeGen/BPF/store_imm.ll

  Log Message:
  -----------
  [BPF] support for BPF_ST instruction in codegen

Generate store immediate instruction when CPUv4 is enabled.
For example:

    $ cat test.c
    struct foo {
      unsigned char  b;
      unsigned short h;
      unsigned int   w;
      unsigned long  d;
    };
    void bar(volatile struct foo *p) {
      p->b = 1;
      p->h = 2;
      p->w = 3;
      p->d = 4;
    }

    $ clang -O2 --target=bpf -mcpu=v4 test.c -c -o - | llvm-objdump -d -
    ...
    0000000000000000 <bar>:
           0:	72 01 00 00 01 00 00 00	*(u8 *)(r1 + 0x0) = 0x1
           1:	6a 01 02 00 02 00 00 00	*(u16 *)(r1 + 0x2) = 0x2
           2:	62 01 04 00 03 00 00 00	*(u32 *)(r1 + 0x4) = 0x3
           3:	7a 01 08 00 04 00 00 00	*(u64 *)(r1 + 0x8) = 0x4
           4:	95 00 00 00 00 00 00 00	exit

Take special care to:
- apply `BPFMISimplifyPatchable::checkADDrr` rewrite for BPF_ST
- validate immediate value when BPF_ST write is 64-bit:
  BPF interprets `(BPF_ST | BPF_MEM | BPF_DW)` writes as writes with
  sign extension. Thus it is fine to generate such write when
  immediate is -1, but it is incorrect to generate such write when
  immediate is +0xffff_ffff.

This commit was previously reverted in e66affa17e32.
The reason for revert was an unrelated bug in BPF backend,
triggered by test case added in this commit if LLVM is built
with LLVM_ENABLE_EXPENSIVE_CHECKS.
The bug was fixed in D157806.

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