[all-commits] [llvm/llvm-project] 7f6bc8: [BPF] Fix a bug for __builtin_preserve_field_info(...

[yonghong-song via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 7f6bc84a97f617f9cf148a96ce72567cfa6066f9
      https://github.com/llvm/llvm-project/commit/7f6bc84a97f617f9cf148a96ce72567cfa6066f9
  Author: Yonghong Song <yhs at fb.com>
  Date:   2020-06-30 (Tue, 30 Jun 2020)

  Changed paths:
    M llvm/lib/Target/BPF/BPFAbstractMemberAccess.cpp
    A llvm/test/CodeGen/BPF/CORE/intrinsic-array-2.ll

  Log Message:
  -----------
  [BPF] Fix a bug for __builtin_preserve_field_info() processing

Andrii discovered a problem where a simple case similar to below
will generate wrong relocation kind:
  enum { FIELD_EXISTENCE = 2, };
  struct s1 { int a1; };
  int test() {
    struct s1 *v = 0;
    return __builtin_preserve_field_info(v[0], FIELD_EXISTENCE);
  }
The expected relocation kind should be FIELD_EXISTENCE, but
recorded reloc kind in the final object file is FIELD_BYTE_OFFSET,
which is incorrect.

This exposed a bug in generating access strings from intrinsics.
The current access string generation has two steps:
  step 1: find the base struct/union type,
  step 2: traverse members in the base type.

The current implementation relies on at lease one member access
in step 2 to get the correct relocation kind, which is true
in typical cases. But if there is no member accesses, the current
implementation falls to the default info kind FIELD_BYTE_OFFSET.
This is incorrect, we should still record the reloc kind
based on the user input. This patch fixed this issue by properly
recording the reloc kind in such cases.

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