use only one relocation for left shift to optimize for direct load. The bpf_probe_read() big endian mode could have 4 more arithmetic instructions compared to little endian mode. The performance impact should be negligible comparing to bpf_probe_read() itself.

separate old FIELD_LSHIFT_U64 relocation to FIELD_LSHIFT_U64_BUF and FIELD_LSHIFT_U64_VAL. This allows to generate better code for native loads.

add test cases. Also handle filed_info for field array elements properly.

fixed a few bugs from previous revision. Removed FIELD_ACCESS_OFFSET relocation which will be identical to FIELD_BYTE_OFFSET. All of these CORE related test cases are adjusted and passed now. Removed [WIP] prefix.
TODO: write new tests for the new functionality.

All these names are not added as builtin enum before compilation starts, right?

Do you prefer to have builtin enum? If we do this, we will emit this enum all the time,
regardless of whether people uses this builtin or not. Are you worried about API
stability?

using 64bit buf always, handling non bitfield members, etc.

return byte_size/offset/lshift/rshift based on size alignment

use a bpf target builtin __builtin_get_field_info().

We will take a different approach. So abandon this revision.

add BPF backend support

builtin return u32 instead of u64.

fix a bug like foo(..., bar(&value), value) where value is set in function bar. This is not right and depends on compiler optimization as there is not guarantee that arguments are evaluated from left to right. The new code looks like a = bar(&value); foo(..., a, value) ...

does not change arg type and make result type the same as arg type

use report_fatal_error() to report errors for missing metadata.

set metadata unless metadata is non-NULL. I have not found a case where metadata is NULL. But nevertheless, let us do this to avoid set a potential NULL metadata.

abandon this one. use git monorepo https://reviews.llvm.org/D65664 since we have llvm/clang inter-dependence here.

abandon this one. use git monorepo https://reviews.llvm.org/D65664 since we have llvm/clang inter-dependence here.

reorder parameter arrayType to make it with default nullptr and simplifies the code.

The clang change https://reviews.llvm.org/D65615.
The BPF backend change https://reviews.llvm.org/D65618.

The corresponding IR intrinsic interface change is at https://reviews.llvm.org/D65617
The BPF backend to utilize this information is at https://reviews.llvm.org/D65618

Abandon this revision for now as one of its variants has been merged.

abandon this one. A revised version with most tests has been merged.

The commit has been merged.

The followup patch for this change is at https://reviews.llvm.org/D64598.

The followup patch for this is at https://reviews.llvm.org/D64606.

@jdoerfert Thanks for commenting on my diff. Will find the appropriate person to review.

change test case so we can test metadata is generated correctly.

@jdoerfert Thanks. I will address your comments and submit standalone test cases for these intrinsics. I do have some BPF unit tests using these intrinsics. But I agree that some standalone unit test cases are also needed.

@jdoerfert Thanks for comments. I will submit another patch to add adequate tests for clang frontend as you suggested.

change some tests where spFlags will not be used in order for the codes easier backport to older compiler (llvm8).

@eli.friedman has reviewed a related patch (https://reviews.llvm.org/D61809) and is okay with the whole approach. @ast is also okay with the patch, so I will start to land soon. Thanks!

@rsmith Ping again, do you have any comments on this patch? Thanks!

for bpf maps section, change from strict .maps section name to .maps* section name, that is, the map section name starts with .maps

fixed a bug in BTFDebug related to btf fwd type generation

@rsmith Just ping, could you take a look at the clang change? If possible, could you share your opinion? Thanks!

handle unnamed bitfield properly. these struct/union members are not encoded in debuginfo, so skip them during preserve_*_access_index IR intrinsics generation.

change void *__builtin_preserve_access_index(void *) to const void * _builtin_preserve_access_index(const void *).

reword the lang doc for builtin_preserve_access_index() to be more user focused
treat using builtin_preserve_access_index() without -g or in nested way as compiler errors

@rsmith I have proposed one clang intrinsic and three IR intrinsics for CO-RE. Could you take a look and share your opinions as well? Thanks!

@eli.friedman Hi, Just ping. I have removed getParents() for ASTContext and added description of the new intrinsic in language doc. Could you take a look? Thanks!

Handling the following case:

@eli.friedman I removed the usage of astcontext getParents() stuff. Instead, I mark the region upfront. I also added the intrinsic __builtin_preserve_access_index() into clang
lang extention doc. Could you take a look at new patch? Thanks!