Skip to content

Conversation

@tambry
Copy link
Contributor

@tambry tambry commented Sep 16, 2025

Scoping to the root build directory instead of using the path directly is awkward and the only such occurrence in the test suite. Pass the appropriate substitution instead for this.

Background
In my downstream %llvmshlibdir is much more nested so the single ../ is insufficient.
But we can use a much more direct substitution rather than a round-about way, which is both cleaner and avoids me needing to patch this test.

@jh7370
Copy link
Collaborator

jh7370 commented Sep 18, 2025

I don't think it's a good idea for me to review this. I've added some other reviewers, who reviewed the original PR that introduced the PR. Also pinging @Tcc100, since they were the one to originally introduce the test.

@arsenm
Copy link
Contributor

arsenm commented Sep 19, 2025

I suppose this is only an issue because the plugin library is built into unittests, and not lib? The other sample plugin binaries just go to the ordinary lib directory

Scoping to the root build directory instead of using the path directly is awkward and the only such
occurrence in the test suite. It's also prone to breakage for downstreams that change the library
path.

But it's not even necessary: during build we have the appropriate RPATHs set so we can just depend
on the dynamic loader to find it. This extra logic is probably just copy-paste from PluginsTest.cpp.

Additionally:
* Removed TargetParser as a dependency because it doesn't seem to actually be used.
* Moved `add_dependencies()` to `DEPENDS` to better match the rest of LLVM.
@tambry tambry force-pushed the codegen_test_obj_root branch from 5c3184d to 2b5b107 Compare September 19, 2025 09:47
@tambry
Copy link
Contributor Author

tambry commented Sep 19, 2025

@arsenm Correct. The other sample plugins don't have any llc tests that manually -load the plugin and run unittests. So this is the only test where both need to work.

But I had another look now and managed to simplify this further. We can actually put the plugin into lib and just rely on the RPATH for it to be found. It's marked BUILDTREE_ONLY so it won't get installed and there seem to be other tests that rely on this too. I think PluginsTest.cpp, which the existing code was likely copy-paste from, could be simplified similarly, but I'll leave that as a follow-up.

@tambry tambry merged commit 4e1c996 into llvm:main Sep 19, 2025
9 checks passed
@tambry tambry deleted the codegen_test_obj_root branch September 19, 2025 11:04
@mgorny
Copy link
Member

mgorny commented Sep 20, 2025

This change introduced test failures for me:

FAIL: LLVM :: Other/codegen-plugin-loading.ll (41910 of 62452)
******************** TEST 'LLVM :: Other/codegen-plugin-loading.ll' FAILED ********************
Exit Code: 1

Command Output (stdout):
--
# RUN: at line 1
/var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/bin/llc -load %llvm_obj_root/unittests/CodeGen/CGPluginTest/CGTestPlugin.so /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll -o - | /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/bin/FileCheck /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll
# executed command: /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/bin/llc -load %llvm_obj_root/unittests/CodeGen/CGPluginTest/CGTestPlugin.so /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll -o -
# .---command stderr------------
# | Error opening '%llvm_obj_root/unittests/CodeGen/CGPluginTest/CGTestPlugin.so': %llvm_obj_root/unittests/CodeGen/CGPluginTest/CGTestPlugin.so: cannot open shared object file: No such file or directory
# |   -load request ignored.
# `-----------------------------
# executed command: /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/bin/FileCheck /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll
# .---command stderr------------
# | /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll:4:10: error: CHECK: expected string not found in input
# | ; CHECK: CodeGen Test Pass running on main
# |          ^
# | <stdin>:1:1: note: scanning from here
# |  .file "codegen-plugin-loading.ll"
# | ^
# | <stdin>:3:12: note: possible intended match here
# |  .globl main // -- Begin function main
# |            ^
# | 
# | Input file: <stdin>
# | Check file: /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm/test/Other/codegen-plugin-loading.ll
# | 
# | -dump-input=help explains the following input dump.
# | 
# | Input was:
# | <<<<<<
# |            1:  .file "codegen-plugin-loading.ll" 
# | check:4'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
# |            2:  .text 
# | check:4'0     ~~~~~~~
# |            3:  .globl main // -- Begin function main 
# | check:4'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# | check:4'1                ?                            possible intended match
# |            4:  .p2align 2 
# | check:4'0     ~~~~~~~~~~~~
# |            5:  .type main,@function 
# | check:4'0     ~~~~~~~~~~~~~~~~~~~~~~
# |            6: main: // @main 
# | check:4'0     ~~~~~~~~~~~~~~~
# |            7:  .cfi_startproc 
# | check:4'0     ~~~~~~~~~~~~~~~~
# |            8: // %bb.0: 
# | check:4'0     ~~~~~~~~~~
# |            .
# |            .
# |            .
# | >>>>>>
# `-----------------------------
# error: command failed with exit status: 1

--

********************

My educated guess is that %llvm_obj_root is not in config.substitutions.

@tambry
Copy link
Contributor Author

tambry commented Sep 20, 2025

@mgorny Seems I forgot to revert one of the substitution changes while rebasing locally. Will fix promptly: #159914.

@mgorny
Copy link
Member

mgorny commented Sep 20, 2025

This path still seems wrong:

# | Error opening '/var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/lib64/unittests/CodeGen/CGPluginTest/CGTestPlugin.so': /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/lib64/unittests/CodeGen/CGPluginTest/CGTestPlugin.so: cannot open shared object file: No such file or directory

I'm seeing:

# find /var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64 -name CGTestPlugin.so
/var/tmp/portage/llvm-core/llvm-22.0.0.9999/work/llvm_build-.arm64/lib64/CGTestPlugin.so

@tambry
Copy link
Contributor Author

tambry commented Sep 20, 2025

@mgorny That's what I get for not waiting my local build and test run to finish... Finally fixed: #159923. 🤞

@mgorny
Copy link
Member

mgorny commented Sep 20, 2025

Yeah, I can confirm it passes now.

tambry added a commit to tambry/llvm-project that referenced this pull request Oct 13, 2025
As proven by llvm#159126 it's unnecessary to explicitly construct the path for loading the test plugins.
On all supported platforms the RPATH is set appropriately for them to be found by the dynamic loader
itself. Thus we can just rid ourselves of the extra code.

This also cleans up some of the CMake code and C++ includes slightly.
Surprisingly `intrinsics_gen` isn't necessary for any of them as none of them actually do much.

See: llvm#159126
tambry added a commit to tambry/llvm-project that referenced this pull request Oct 13, 2025
As proven by llvm#159126 it's unnecessary to explicitly construct the path for loading the test plugins.
On all supported platforms the RPATH is set appropriately for them to be found by the dynamic loader
itself. Thus we can just rid ourselves of the extra code.

This also cleans up some of the CMake code and C++ includes slightly.
Surprisingly `intrinsics_gen` isn't necessary for any of them as none of them actually do much.

See: llvm#159126
tambry added a commit to tambry/llvm-project that referenced this pull request Oct 13, 2025
As proven by llvm#159126 it's unnecessary to explicitly construct the path for loading the test plugins.
On all supported platforms the rpath is set appropriately for them to be found by the dynamic loader
itself. Thus we can just rid ourselves of the extra code.

The only exception is `Support/DynamicLibrary` as it also runs on Windows, which lacks the concept
of a rpath.

This also cleans up some of the CMake code and C++ includes slightly.
Surprisingly `intrinsics_gen` isn't necessary for any of them as none of them actually do much.

See: llvm#159126
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants