This is an archive of the discontinued LLVM Phabricator instance.

[llvm][LLParser] Fix issue with forward-referenced dso_local_equivalent globals
AbandonedPublic

Authored by leonardchan on Oct 7 2022, 12:51 PM.

Details

Summary

llc would fail with this IR:

; RUN:llc -mtriple=x86_64-linux-gnu -o - %s
@_ZTV1B_rv = constant i32 trunc (i64 sub (i64 ptrtoint (void ()* dso_local_equivalent @_ZN1B1fEi to i64), i64 ptrtoint (i32* getelementptr inbounds (i32, i32* @_ZTV1B_rv, i32 0) to i64)) to i32)

define void @_ZN1B1fEi() {
   ret void
}

bin/llc: error: bin/llc: /usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-2/llvm/test/ThinLTO/X86/dso_local_equivalent.ll:6:66: error: constant expression type mismatch: got type 'i8*' but expected 'void ()*'

The issue is that the forward referenced placeholder globalvariable is being type-checked with _ZN1B1fEi once we finish parsing its name and type. This patch ensures the placeholder will only be established if we know what type it should be. In globals, this is straightforward where the expected type is given before dso_local_equivalent. For calls where we may not know the type of the forward-referenced callee, we can lazily create the placeholder until the type is known.

Diff Detail

Event Timeline

leonardchan created this revision.Oct 7 2022, 12:51 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 7 2022, 12:51 PM
leonardchan requested review of this revision.Oct 7 2022, 12:51 PM
nikic added a subscriber: nikic.

This seems to add some non-trivial complexity for something that is only relevant for typed pointers. Why do you need this at this point in time?

This seems to add some non-trivial complexity for something that is only relevant for typed pointers. Why do you need this at this point in time?

I'm writing tests to get [thin]lto to support relative vtables (D134320). One of the recommendations for ensuring thinlto support was writing equivalent tests to llvm/test/ThinLTO/X86/devirt.ll but using the relative vtable layout which uses dso_local_equivalent, so I'm essentially reusing a lot of what's in that file for testing RV. That is, for each test case I see for a regular vtable I'll test for a relative vtable. It just so happens that test and a lot of the whole program devirtualization tests in general still use typed pointers.

can we migrate the WPD tests to use opaque pointers? https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34 is the script to do that

can we migrate the WPD tests to use opaque pointers? https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34 is the script to do that

Uploaded https://reviews.llvm.org/D135611 which updates everything under llvm/test/Transforms/WholeProgramDevirt/. Needed some non-trivial manual updating though for a handful of tests. I suspect I'll run into more failures requiring manual tuning if I were to update the thinlto tests as well. What's the current plan for migrating llvm tests to unique pointers? I see on the opaque ptrs doc that by llvm 16, type pointers will no longer be supported but it looks like there's still a lot of llvm tests that still use typed pointers. Will all of them go through a mass migration using this script? One worry I have is I (or other test owners) will need to spend a non-trivial amount of time fixing tests.

nikic added a comment.Dec 8 2022, 8:02 AM

This one can probably be abandoned per above discussion?

leonardchan abandoned this revision.Dec 8 2022, 11:02 AM

This one can probably be abandoned per above discussion?

Yup