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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
