Changes in intrinsic-array.ll

edb2fc6dab2cf04779959829434e9e8572d48a26 - [llvm] Remove explicit -opaque-pointers flag from tests (NFC)

Wed, 12 Jul 2023 12:19:34 +0000

[llvm] Remove explicit -opaque-pointers flag from tests (NFC)Opaque pointers mode is enabled by default, no need to explicitlyenable it. List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

60228733726e25d011b1f9221e005732191cc077 - [BPF] Convert some tests to opaque pointers (NFC)

Mon, 19 Dec 2022 11:46:13 +0000

[BPF] Convert some tests to opaque pointers (NFC) List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

90ec6dff860f4ec9cb89041b6e2a671cc3ce8f47 - [OpaquePtr] Forbid mixing typed and opaque pointers

Sat, 04 Sep 2021 10:18:52 +0000

[OpaquePtr] Forbid mixing typed and opaque pointersCurrently, opaque pointers are supported in two forms: The-force-opaque-pointers mode, where all pointers are opaque andtyped pointers do not exist. And as a simple ptr type that cancoexist with typed pointers.This patch removes support for the mixed mode. You either gettyped pointers, or you get opaque pointers, but not both. In the(current) default mode, using ptr is forbidden. In -opaque-pointersmode, all pointers are opaque.The motivation here is that the mixed mode introduces additionalissues that don't exist in fully opaque mode. D105155 is an exampleof a design problem. Looking at D109259, it would probably needadditional work to support mixed mode (e.g. to generate GEPs fortyped base but opaque result). Mixed mode will also end upinserting many casts between i8* and ptr, which would requiresignificant additional work to consistently avoid.I don't think the mixed mode is particularly valuable, as itdoesn't align with our end goal. The only thing I've found it tobe moderately useful for is adding some opaque pointer tests inbetween typed pointer tests, but I think we can live without that.Differential Revision: https://reviews.llvm.org/D109290 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

be5af50e7d028849bf2fab5f4b0f2ad36ae56e11 - [BPF] Use elementtype attribute for preserve.array/struct.index intrinsics

Fri, 16 Jul 2021 18:26:40 +0000

[BPF] Use elementtype attribute for preserve.array/struct.index intrinsicsUse the elementtype attribute introduced in D105407 for thellvm.preserve.array/struct.index intrinsics. It carries theelement type of the GEP these intrinsics effectively encode.This patch: * Adds a verifier check that the attribute is required. * Adds it in the IRBuilder methods for these intrinsics. * Autoupgrades old bitcode without the attribute. * Updates the lowering code to use the attribute rather than the pointer element type. * Updates lots of tests to specify the attribute. * Adds -force-opaque-pointers to the intrinsic-array.ll test to demonstrate they work now.https://reviews.llvm.org/D106184 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

4ab3041acbdc274050d6c53f72619c7455cbc97a - Revert "[NFC] remove explicit default value for strboolattr attribute in tests"

Mon, 24 May 2021 17:43:40 +0000

Revert "[NFC] remove explicit default value for strboolattr attribute in tests"This reverts commit bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247.See https://lab.llvm.org/buildbot/#/builders/109/builds/15424 for instance List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

bda6e5bee04c75b1f1332b4fd1ac4e8ef6c3c247 - [NFC] remove explicit default value for strboolattr attribute in tests

Sun, 23 May 2021 11:19:23 +0000

[NFC] remove explicit default value for strboolattr attribute in testsSince d6de1e1a71406c75a4ea4d5a2fe84289f07ea3a1, no attributes is quivalent tosetting attribute to false.This is a preliminary commit for https://reviews.llvm.org/D99080 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

54d9f743c8b0f501288119123cf1828bf7ade69c - BPF: move AbstractMemberAccess and PreserveDIType passes to EP_EarlyAsPossible

Thu, 03 Sep 2020 05:56:41 +0000

BPF: move AbstractMemberAccess and PreserveDIType passes to EP_EarlyAsPossibleMove abstractMemberAccess and PreserveDIType passes as early aspossible, right after clang code generation.Currently, compiler may transform the above code p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); a = llvm.bpf.builtin.preserve_field_info(p2, EXIST); if (a) { p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); bpf_probe_read(buf, buf_size, p2); }to p1 = llvm.bpf.builtin.preserve.struct.access(base, 0, 0); p2 = llvm.bpf.builtin.preserve.struct.access(p1, 1, 2); a = llvm.bpf.builtin.preserve_field_info(p2, EXIST); if (a) { bpf_probe_read(buf, buf_size, p2); }and eventually assembly code looks like reloc_exist = 1; reloc_member_offset = 10; //calculate member offset from base p2 = base + reloc_member_offset; if (reloc_exist) { bpf_probe_read(bpf, buf_size, p2); }if during libbpf relocation resolution, reloc_exist is actuallyresolved to 0 (not exist), reloc_member_offset relocation cannotbe resolved and will be patched with illegal instruction.This will cause verifier failure.This patch attempts to address this issue by do chaininganalysis and replace chains with special globals rightafter clang code gen. This will remove the cse possibilitydescribed in the above. The IR typically looks like %6 = load @llvm.sk_buff:0:50$0:0:0:2:0 %7 = bitcast %struct.sk_buff* %2 to i8* %8 = getelementptr i8, i8* %7, %6for a particular address computation relocation.But this transformation has another consequence, code sinkingmay happen like below: PHI = %7 = bitcast %struct.sk_buff* %2 to i8* %8 = getelementptr i8, i8* %7, %6For such cases, we will not able to generate relocations sincemultiple relocations are merged into one.This patch introduced a passthrough builtinto prevent such optimization. Looks like inline assembly has moreimpact for optimizaiton, e.g., inlining. Using passthrough hasless impact on optimizations.A new IR pass is introduced at the beginning of target-dependentIR optimization, which does: - report fatal error if any reloc global in PHI nodes - remove all bpf passthrough builtin functionsChanges for existing CORE tests: - for clang tests, add "-Xclang -disable-llvm-passes" flags to avoid builtin->reloc_global transformation so the test is still able to check correctness for clang generated IR. - for llvm CodeGen/BPF tests, add "opt -O2 | llvm-dis" command before "llc" command since "opt" is needed to call newly-placed builtin->reloc_global transformation. Add target triple in the IR file since "opt" requires it. - Since target triple is added in IR file, if a test may produce different results for different endianness, two tests will be created, one for bpfeb and another for bpfel, e.g., some tests for relocation of lshift/rshift of bitfields. - field-reloc-bitfield-1.ll has different relocations compared to old codes. This is because for the structure in the test, new code returns struct layout alignment 4 while old code is 8. Align 8 is more precise and permits double load. With align 4, the new mechanism uses 4-byte load, so generating different relocations. - test intrinsic-transforms.ll is removed. This is used to test cse on intrinsics so we do not lose metadata. Now metadata is attached to global and not instruction, it won't get lost with cse.Differential Revision: https://reviews.llvm.org/D87153 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

502a77f125f43ffde57af34d3fd1b900248a91cd - Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" as cleanups after D56351

Tue, 24 Dec 2019 23:52:21 +0000

Migrate function attribute "no-frame-pointer-elim" to "frame-pointer"="all" as cleanups after D56351 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

a27c998c0060eef006ca9e225e4d12a35f4d1912 - [BPF] fix a CO-RE issue with -mattr=+alu32

Fri, 25 Oct 2019 05:57:06 +0000

[BPF] fix a CO-RE issue with -mattr=+alu32Ilya Leoshkevich () reported an issue thatwith -mattr=+alu32 CO-RE has a segfault in BPF MISimplifyPatchablepass.The pattern will be transformed by MISimplifyPatchablepass looks like below: r5 = ld_imm64 @"b:0:0$0:0" r2 = ldw r5, 0 ... r2 ... // use r2The pass will remove the intermediate 'ldw' instructionand replacing all r2 with r5 likes below: r5 = ld_imm64 @"b:0:0$0:0" ... r5 ... // use r5Later, the ld_imm64 insn will be replaced with r5 = for field relocation purpose.With -mattr=+alu32, the input code may become r5 = ld_imm64 @"b:0:0$0:0" w2 = ldw32 r5, 0 ... w2 ... // use w2Replacing "w2" with "r5" is incorrect and willtrigger compiler internal errors.To fix the problem, if the register class of ldw* destregister is sub_32, we just replace the original ldw*register with: w2 = w5Directly replacing all uses of w2 with in-placeconstructed w5 for the use operand seems not working in all cases.The latest kernel will have -mattr=+alu32 on by default,so added this flag to all CORE tests.Tested with latest kernel bpf-next branch as well with this patch.Differential Revision: https://reviews.llvm.org/D69438 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

05e46979d2f4ba709400e43716b5c37d3d46d329 - [BPF] do compile-once run-everywhere relocation for bitfields

Tue, 08 Oct 2019 18:23:17 +0000

[BPF] do compile-once run-everywhere relocation for bitfieldsA bpf specific clang intrinsic is introduced: u32 __builtin_preserve_field_info(member_access, info_kind)Depending on info_kind, different information willbe returned to the program. A relocation is alsorecorded for this builtin so that bpf loader canpatch the instruction on the target host.This clang intrinsic is used to get certain informationto facilitate struct/union member relocations.The offset relocation is extended by 4 bytes toinclude relocation kind.Currently supported relocation kinds are enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64, };for __builtin_preserve_field_info. The oldaccess offset relocation is covered by FIELD_BYTE_OFFSET = 0.An example:struct s { int a; int b1:9; int b2:4;};enum { FIELD_BYTE_OFFSET = 0, FIELD_BYTE_SIZE, FIELD_EXISTENCE, FIELD_SIGNEDNESS, FIELD_LSHIFT_U64, FIELD_RSHIFT_U64,};void bpf_probe_read(void *, unsigned, const void *);int field_read(struct s *arg) { unsigned long long ull = 0; unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET); unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE); #ifdef USE_PROBE_READ bpf_probe_read(&ull, size, (const void *)arg + offset); unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ lshift = lshift + (size << 3) - 64; #endif #else switch(size) { case 1: ull = *(unsigned char *)((void *)arg + offset); break; case 2: ull = *(unsigned short *)((void *)arg + offset); break; case 4: ull = *(unsigned int *)((void *)arg + offset); break; case 8: ull = *(unsigned long long *)((void *)arg + offset); break; } unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64); #endif ull <<= lshift; if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS)) return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64); return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64);}There is a minor overhead for bpf_probe_read() on big endian.The code and relocation generated for field_read where bpf_probe_read() isused to access argument data on little endian mode: r3 = r1 r1 = 0 r1 = 4 <=== relocation (FIELD_BYTE_OFFSET) r3 += r1 r1 = r10 r1 += -8 r2 = 4 <=== relocation (FIELD_BYTE_SIZE) call bpf_probe_read r2 = 51 <=== relocation (FIELD_LSHIFT_U64) r1 = *(u64 *)(r10 - 8) r1 <<= r2 r2 = 60 <=== relocation (FIELD_RSHIFT_U64) r0 = r1 r0 >>= r2 r3 = 1 <=== relocation (FIELD_SIGNEDNESS) if r3 == 0 goto LBB0_2 r1 s>>= r2 r0 = r1LBB0_2: exitCompare to the above code between relocations FIELD_LSHIFT_U64 andFIELD_LSHIFT_U64, the code with big endian mode has four moreinstructions. r1 = 41 <=== relocation (FIELD_LSHIFT_U64) r6 += r1 r6 += -64 r6 <<= 32 r6 >>= 32 r1 = *(u64 *)(r10 - 8) r1 <<= r6 r2 = 60 <=== relocation (FIELD_RSHIFT_U64)The code and relocation generated when using direct load. r2 = 0 r3 = 4 r4 = 4 if r4 s> 3 goto LBB0_3 if r4 == 1 goto LBB0_5 if r4 == 2 goto LBB0_6 goto LBB0_9LBB0_6: # %sw.bb1 r1 += r3 r2 = *(u16 *)(r1 + 0) goto LBB0_9LBB0_3: # %entry if r4 == 4 goto LBB0_7 if r4 == 8 goto LBB0_8 goto LBB0_9LBB0_8: # %sw.bb9 r1 += r3 r2 = *(u64 *)(r1 + 0) goto LBB0_9LBB0_5: # %sw.bb r1 += r3 r2 = *(u8 *)(r1 + 0) goto LBB0_9LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0)LBB0_9: # %sw.epilog r1 = 51 r2 <<= r1 r1 = 60 r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2LBB0_11: # %sw.epilog exitConsidering verifier is able to do limited constantpropogation following branches. The following is thecode actually traversed. r2 = 0 r3 = 4 <=== relocation r4 = 4 <=== relocation if r4 s> 3 goto LBB0_3LBB0_3: # %entry if r4 == 4 goto LBB0_7LBB0_7: # %sw.bb5 r1 += r3 r2 = *(u32 *)(r1 + 0)LBB0_9: # %sw.epilog r1 = 51 <=== relocation r2 <<= r1 r1 = 60 <=== relocation r0 = r2 r0 >>= r1 r3 = 1 if r3 == 0 goto LBB0_11 r2 s>>= r1 r0 = r2LBB0_11: # %sw.epilog exitFor native load case, the load size is calculated to be thesame as the size of load width LLVM otherwise used to loadthe value which is then used to extract the bitfield value.Differential Revision: https://reviews.llvm.org/D67980llvm-svn: 374099 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

d0ea05d5eff475a27a5d3bbe4d9fd389935f9cb2 - [BPF] annotate DIType metadata for builtin preseve_array_access_index()

Fri, 02 Aug 2019 21:28:28 +0000

[BPF] annotate DIType metadata for builtin preseve_array_access_index()Previously, debuginfo types are annotated toIR builtin preserve_struct_access_index() andpreserve_union_access_index(), but notpreserve_array_access_index(). The debug infois useful to identify the root type name whichlater will be used for type comparison.For user access without explicit type conversions,the previous scheme works as we can ignore intermediatecompiler generated type conversions (e.g., from union types tounion members) and still generate correct access index string.The issue comes with user explicit type conversions, e.g.,converting an array to a structure like below: struct t { int a; char b[40]; }; struct p { int c; int d; }; struct t *var = ...; ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ...Although BPF backend can derive the type of &(var->b[0]),explicit type annotation make checking more consistentand less error prone.Another benefit is for multiple dimension array handling.For example, struct p { int c; int d; } g[8][9][10]; ... __builtin_preserve_access_index(&g[2][3][4].d) ...It would be possible to calculate the number of "struct p"'sbefore accessing its member "d" if array debug info isavailable as it contains each dimension range.This patch enables to annotate IR builtin preserve_array_access_index()with proper debuginfo type. The unit test case and language referenceis updated as well.Signed-off-by: Yonghong Song Differential Revision: https://reviews.llvm.org/D65664llvm-svn: 367724 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll

c3805d761ea8be6f35212a29aec09f03f1be5612 - [BPF] add unit tests for preserve_{array,union,struct}_access_index intrinsics

Mon, 15 Jul 2019 04:51:34 +0000

[BPF] add unit tests for preserve_{array,union,struct}_access_index intrinsicsThis is a followup patch for https://reviews.llvm.org/D61810/new/,which adds new intrinsics preserve_{array,union,struct}_access_index.Currently, only BPF backend utilizes preserve_{array,union,struct}_access_indexintrinsics, so all tests are compiled with BPF target.https://reviews.llvm.org/D61524 already added some tests for theseintrinsics, but some of them pretty complex.This patch added a few unit test cases focusing on individual intrinsicfunctions.Also made a few clarification on language reference for these intrinsics.Differential Revision: https://reviews.llvm.org/D64606llvm-svn: 366038 List of files: /llvm-project/llvm/test/CodeGen/BPF/CORE/intrinsic-array.ll