Enabling opaque pointers by default

As a few people have been asking about this recently, I’ve put up ⚙ D140487 [Docs] Clarify typed pointers support timeline to commit to a hard timeline for typed pointer support. The tl;dr is that independent of test migration state, LLVM 16 will retain best-effort support for typed pointers, and LLVM 17 will not support them as a matter of policy (immediately after branching, i.e. from Jan 24th).

Hi everyone!

I have question related to opaque pointers.
Can we get the contained type of an element of an array, when the element is just marked ptr? Shortly saying the underlying type of “ptr” element type of an array.

No, this is not possible (unless we’re talking about a special case, like a global array). If you provide some more context on what you’re trying to do, there’s likely some alternative way to achieve it though.

I have a scenario where I need to know type of an element of an array, and I wonder if there’s an alternative way to achieve it?

For [AArch64] Performance is now affected due to unaligned access · Issue #59912 · llvm/llvm-project · GitHub, we can find the following IR in LoopPeel pass, I wonder whether the first element a[0] in the kernel loop body of function callee is aligned 16-byte? However, as the data type is ‘ptr’, so it cannot be obtained.

define dso_local void @callee(ptr nocapture noundef writeonly %a, i32 noundef %n) local_unnamed_addr #0 {
entry:
  %cmp4 = icmp sgt i32 %n, 0
  br i1 %cmp4, label %for.body.preheader, label %for.cond.cleanup

for.body.preheader:                               ; preds = %entry
  %wide.trip.count = zext i32 %n to i64
br label %for.body

for.cond.cleanup.loopexit:                        ; preds = %for.body
  br label %for.cond.cleanup

for.cond.cleanup:                                 ; preds = %for.cond.cleanup.loopexit, %entry
  ret void

for.body: ; preds = %for.body.preheader, %for.body
%Warnings.IV = phi i64 [ 0% for.body.preheader ], [ %warning.iv.next, %for.body ]
%0 = trunc i64% iv two i32
%m = mulnw i32%0, 50
%arrayidx = getelptr in bounds i32, ptr %a, i64%invars.iv
large i32%mul, ptr%arrayidx, align 4!tbaa!6
%WARNING.IV.next = add nuw nsw i64%Warnings.iv, 1
  %exitcond = icmp ne i64 %indvars.iv.next, %wide.trip.count
  br i1 %exitcond, label %for.body, label %for.cond.cleanup.loopexit, !llvm.loop !10
}

@Allen Pointer element types have no relation to alignment. Alignment is determined either by annotations on the access, or through align attributes. LLVM provides helpers to determine the alignment, the most primitive one is getPointerAlignment(), and the most powerful is getOrEnforceKnownAlignment().

However, if I understand that issue correctly, the idea there is to insert a runtime check on the alignment, rather than make use of known alignment.

Yes, here need a runtime check.Thanks @nikic.

As another update, ⚙ D141912 [AsmParser] Remove typed pointer auto-detection removes auto-detection of typed pointers from the IR parser. This means that explicitly specifying -opaque-pointers=0 is now always necessary to prevent an opaque pointer auto-upgrade.

This is also your final reminder that, as a matter of policy, typed pointers will not be supported once the release/16.x branch has been created on Jan 24th.

As previously announced, typed pointers are no longer supported on the main branch: [Docs] Typed pointers are no longer supported · llvm/llvm-project@5f313c9 · GitHub

For now this is just a policy statement, but expect bits of typed pointer support code to start getting removed in the near future.

All remaining tests that rely on typed pointers are marked with either -no-opaque-pointers or -opaque-pointers=0. Help in migrating these (especially on the clang side), would be greatly appreciated.

1 Like

@nikic

However, tests are still in the process of being converted to opaque pointers. As such, care must be taken when actively removing typed pointer support, to avoid breaking remaining tests.

Do you have a plan for removing typed pointer support? It doesn’t seem it can be automated.
E.g. mark PointerType::get(Type *EltTy, unsigned AddressSpace) as deprecated, insert an assert and fix places where it triggers, or …
I’d like to help, but it would be nice to see an example patch first.

We’re not yet at a point where core APIs like these can be removed (or deprecated – that requires removing all monorepo callers first).

There is still a substantial amount of remaining tests that use the -no-opaque-pointers or -opaque-pointers=0 options, and these need to be converted before we can remove anything substantial.

If you’d like to help with test migration, the general process is to run the migration script on some test(s), and then fix up the test failure (if you’re lucky by rerunning an update_test_checks script, but for clang tests usually manually).

If you’d like to help with test migration, the general process is to run the migration script on some test(s), and then fix up the test failure (if you’re lucky by rerunning an update_test_checks script, but for clang tests usually manually).

OK, I’ll try to address CodeGen/PowerPC tests.

1 Like

I’ve been able to convert most PPC tests to opaque pointers. The remaining three tests are large and converting them results in significant changes in the generated code. I’ll leave them to someone who is more familiar with the architecture.