[PATCH] D83242: [clang][BPF] support type exist/size and enum exist/value relocations

Yonghong Song via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Aug 3 21:58:05 PDT 2020


yonghong-song added a comment.

In D83242#2192130 <https://reviews.llvm.org/D83242#2192130>, @anakryiko wrote:

> LGTM. One question: why didn't we run into the need for SeqNumVal trick with field-based relocations? We seem to need it for all other types (including type ID-based), but not for field-based?

good question. In general CSE can only happen if
the base address is the same, for a->b->c->d and a->b->c, portion of address calculation may be shared (CSE'ed).
If the base address is different (e.g., as different variable), CSE cannot happen since the base address is different.

The CSE with different types can happen if the base address is nullptr. This may happen when you try to test
whether a member exists or not. For example:

-bash-4.4$ cat t.c
struct t { int a; int b; };
typedef struct t __t;
int test(struct t *arg1, __t *arg2) {

  return __builtin_preserve_field_info(((struct t *)0)->b, 1) +
         __builtin_preserve_field_info(((__t *)0)->b, 1);

}
-bash-4.4$

Although clang generates two IR builtins tagged with "struct t" and "__t" debuginfo type respectively, the IR type for the first argument base is the same as "struct t" as typedef is ignored at IR level. So in this case, two __builtin_preserve_field_info will be CSE'ed to one. I think this is okay, we are trying to test whether a field is available, the correct result is still returned.

This is different than testing whether a type exists or not where we want to precisely test whether that type exists or not, so we want to preserve `typedef` type vs. `struct t` type.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83242/new/

https://reviews.llvm.org/D83242



More information about the cfe-commits mailing list