This is an archive of the discontinued LLVM Phabricator instance.

[bazel] Restore libpfm as a conditional dependency for exegesis.
ClosedPublic

Authored by rupprecht on Nov 21 2022, 7:36 PM.

Details

Summary

We used to have pfm built into exegesis, although since it's an external dependency we marked it as a manual target. Because of this we didn't have buildbot coverage and so we removed it in D134510 after we had a few breakages that weren't caught. This adds it back, but with three possible states similar to the story with mpfr, i.e. it can either be disabled, built from external sources (git/make), or use whatever -lpfm is installed on the system.

This change is modeled after D119547. Like that patch, the default is off (matching the status quo), but unlike that patch we don't enable it for CI because IIRC we don't have the package installed there, and building from source might be expensive. We could enable it later either after installing it on buildbot machines or by measuring build cost and deeming it OK.

Diff Detail

Event Timeline

rupprecht created this revision.Nov 21 2022, 7:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 21 2022, 7:36 PM
Herald added a subscriber: mstojanovic. · View Herald Transcript
rupprecht requested review of this revision.Nov 21 2022, 7:36 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 21 2022, 7:36 PM

libpfm4-dev was installed on the postsubmit bot but not the presubmit bot, I've installed it on the presubmit bot

you should be able to make the same change as D119547 to utils/bazel/.bazelrc

I'm not qualified to review this, but thanks for making it work !

gchatelet added a comment.EditedNov 22 2022, 1:49 AM

LGTM. Thx @aeubanks for installing libpfm on the CI bots.

I just have a question about disabling Exegesis in case libpfm is disabled (see below)
FTR D119547 uses external as the default policy which builds from source.

@rupprecht this patch will require a bit of integration downstream.

utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2770

AFAIU it doesn't make sense to build Exegesis without libpfm so I would do something similar to
https://github.com/llvm/llvm-project/blob/ee82b864f2086f944f046bd00b03f30697403f8a/utils/bazel/llvm-project-overlay/libc/utils/MPFRWrapper/BUILD.bazel#L13-L16

This makes sure that the target is skipped when using wildcards (which is the case on CI).

gchatelet added inline comments.Nov 22 2022, 6:15 AM
utils/bazel/third_party_build/pfm.BUILD
15

Remove if not needed

GMNGeoffrey accepted this revision.Nov 22 2022, 10:45 AM
GMNGeoffrey added inline comments.
utils/bazel/WORKSPACE
16–17

This formatting looks wrong to me. These are kwargs

utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2728

Do we want all transitive dependencies to have that defined? It might be better to have the selects in more places and add it in local_defines (note not copts)

2770

I think it's fine to have it without? That's what we had before this patch

This revision is now accepted and ready to land.Nov 22 2022, 10:45 AM
gchatelet added inline comments.Nov 23 2022, 1:31 AM
utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2770

No strong opinion here, I'm fine with the status quo.

rupprecht marked 2 inline comments as done.
  • Use system pfm for CI
  • Undo bad buildifier change
  • Remove leftover configure_options from a previous attempt
  • Make "external" the default.

FTR D119547 uses external as the default policy which builds from source.

Made it the default for this too, then.

utils/bazel/WORKSPACE
16–17

Weird, buildifier did this.

Since starlark is sort-of-but-not-really-python this might actually be the expected format. I'll just undo it for now though.

utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2728

I personally think it makes sense to have this apply transitively. This is basically a shim config target that either says "I have pfm" or "I am missing pfm", so advertising that pervasively is an intended goal. If this causes a build target downstream to behave differently, it's because it has a "#ifdef HAVE_LIBPFM" somewhere, and it should be depending on this anyway.

I think the warning that this applies transitively and recommending that one use local defines is in case you build one target with "-UNDEBUG" and then accidentally make all your dependencies run slower because debug mode is enabled everywhere. That's good general advice but not what's happening here.

If we don't do it this way, then we have to:

  1. Set copts on "Exegesis"
  2. Set copts and linkopts on "llvm-exegesis"
  3. Set copts and linkopts on "llvm_exegesis_tests"

Not a whole lot to do if we go down that road, but I think this is simpler.

2770

I'm leaning toward leaving it like this too just because that's what we currently have.

This revision was landed with ongoing or failed builds.Dec 28 2022, 8:13 AM
This revision was automatically updated to reflect the committed changes.

I am using LLVM Bazel repository without LLVM's WORKSPACE.

utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2764

I think the naming of @pfm//:pfm_external would be different from other external libraries like @llvm_foobar//:foobar

rupprecht added inline comments.Dec 29 2022, 6:23 PM
utils/bazel/llvm-project-overlay/llvm/BUILD.bazel
2764

I don't have a strong preference for this name, I just lifted the naming scheme from D119547, e.g. which uses "@mpfr//:mpfr_external" and others for different ways to depend on mpfr. I'm not well versed in the style guide/naming scheme for these kinds of files so I just went with consistency with something else.

For the repo name, I think "@llvm_pfm" would be fine. Is the idea that we name it "@llvm_pfm" and not "@pfm" to clarify that the configuration for setting up pfm is local to the llvm-project repository, i.e. we're not pulling a bzl configuration from pfm's repo?

For the target name, I personally don't think just ":pfm" would be ideal, because it isn't as explicit about which pfm is being used. But if we wanted to use a different name instead of "external", that's totally fine with me.