This is an archive of the discontinued LLVM Phabricator instance.

Update benchmarks
ClosedPublic

Authored by mtrofin on Mar 9 2022, 2:53 PM.

Details

Summary

This mainly updates benchmarks to address an issue with perfcounters
introduced through a refactoring. The issue was fixed in
https://github.com/google/benchmark/pull/1308.

The only other change is in XRay - there was an update in the State
API - field accessors.

Diff Detail

Repository
rT test-suite

Event Timeline

mtrofin created this revision.Mar 9 2022, 2:53 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 9 2022, 2:53 PM
mtrofin requested review of this revision.Mar 9 2022, 2:53 PM
jdoerfert accepted this revision.Mar 10 2022, 11:49 AM

LG, given that this simply updates an external dependence. Assuming nothing breaks...

This revision is now accepted and ready to land.Mar 10 2022, 11:49 AM
This revision was automatically updated to reflect the committed changes.

This patch adds visibility options, which isn't supported on AIX and causes build failure.
https://lab.llvm.org/buildbot/#/builders/214/builds/370/steps/9/logs/stdio

I'm working on a patch to guard visibility on AIX, but please let me know if there is a quick fix.

jroelofs added inline comments.
MicroBenchmarks/libs/benchmark/src/CMakeLists.txt
47

This seems to have broken several of the test-suite-verify-machineinstrs bots on GreenDragon:

https://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-aarch64-O3//11371/consoleFull

I don't understand how it's happening though, since the CheckLibraryExists test for it passes, setting HAVE_LIB_RT true:

-- Looking for shm_open in rt
-- Looking for shm_open in rt - found

But later the link fails with:

ld: library not found for -lrt

Any ideas?

mtrofin added inline comments.Apr 2 2022, 8:43 AM
MicroBenchmarks/libs/benchmark/src/CMakeLists.txt
47

It seems before we were doing find_library, I wonder if there is a nuance in cmake / cmake on OSX that is the issue here? Asking on the github side, too (https://github.com/google/benchmark/commit/eb9100bf4124e69d0c167361acedb8cab1e79f5e#r702892140)

Could you meanwhile try re-adding the find_library here, and if that works, I'll patch both here and upstream accordingly?

mtrofin added inline comments.Apr 2 2022, 9:51 AM
MicroBenchmarks/libs/benchmark/src/CMakeLists.txt
47

Based on the comments on github (https://github.com/google/benchmark/commit/eb9100bf4124e69d0c167361acedb8cab1e79f5e#r702892140), it seems there may be a problem with the bot setup (because llvm-test-suite on linux seems to work, and benchmark on macosx seems to work)

Happy to help, but I only have a x86 mac.

This is also hitting the x86-64 macOS bots 😢

https://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O3/

I wonder if the issue is something to do with how we set up the Xcode SDK? Both the AArch64 + x86 test suite builders use this CMake cache:

https://github.com/llvm/llvm-zorg/blob/f785f4216432aa0d249ee3ad1f86515caf4c7b10/tasks/cmake/caches/util/xcode_sdk.cmake

@mtrofin, does anything stand out to you here?

This is also hitting the x86-64 macOS bots 😢

https://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O3/

I wonder if the issue is something to do with how we set up the Xcode SDK? Both the AArch64 + x86 test suite builders use this CMake cache:

https://github.com/llvm/llvm-zorg/blob/f785f4216432aa0d249ee3ad1f86515caf4c7b10/tasks/cmake/caches/util/xcode_sdk.cmake

@mtrofin, does anything stand out to you here?

Looking - I'll also try building locally, I have a OSX intel I should (hopefully!) be able to repro on.

This is also hitting the x86-64 macOS bots 😢

https://green.lab.llvm.org/green/job/test-suite-verify-machineinstrs-x86_64-O3/

I wonder if the issue is something to do with how we set up the Xcode SDK? Both the AArch64 + x86 test suite builders use this CMake cache:

https://github.com/llvm/llvm-zorg/blob/f785f4216432aa0d249ee3ad1f86515caf4c7b10/tasks/cmake/caches/util/xcode_sdk.cmake

Quick question: do the build directories get wiped out between builds (including cmake caches)?

@mtrofin, does anything stand out to you here?

@mtrofin Everything these bots does is sets up a fresh environment each time, so there ought to be nothing left over from previous runs. Everything is done in a new directory each time IIRC, so we get a clean build every time.

@mtrofin Everything these bots does is sets up a fresh environment each time, so there ought to be nothing left over from previous runs. Everything is done in a new directory each time IIRC, so we get a clean build every time.

Hmm. When trying to repro locally (Monterey, 12.3.1, Xcode command line tools 13.3.1[*]), librt is not found in the first place. Looking at the logs for the google/benchmark project, the macosx builds there don't find librt either (e.g. https://github.com/google/benchmark/runs/5968639052?check_suite_focus=true)

A bit of searching online indicates that apparently librt shouldn't be on macosx anyway.

I'm not super-familiar with Jenkins, so I'm still digging around logs, but if you are/have access to how the bots are set up, could you check where this librt that shouldn't be there even is? Alternatively, is there a way to run the bots with a patch from a branch - thinking we can add some cmake messages there and figure out what librt is found.

  • couldn't install the version the bots use because 'it was too old'

As a workaround, what if we wrapped the check in an if(NOT APPLE)?

As a workaround, what if we wrapped the check in an if(NOT APPLE)?

We could, but it probably doesn't make sense to do in google/benchmarks upstream, because (from the looks of it) the problem is with the build bot setup. If there is an ongoing plan to figure out the latter, I'd support "let's patch locally" to green-up the bots, as a stop-gap measure (with caveats that it'd be best to not go down this path for too long and with too many cases, as we'll get back to maintaining a fork, etc, etc). wdyt?

jroelofs added a subscriber: fhahn.May 9 2022, 3:05 PM

@fhahn suggested this might be an issue with how caches/util/xcode_sdk.cmake configures try_compile, and sure enough:

[14:55:41] ✔ jroelofs@galois build$ cat ../CMakeLists.txt 
project(ReproLibRtDarwin)
cmake_minimum_required(VERSION 3.23)

include(CheckLibraryExists)

# This set is load-bearing:
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY CACHE STRING "")

check_library_exists(rt shm_open "" HAVE_LIB_RT)

if(HAVE_LIB_RT)
  message(WARNING "FAILURE: should not have found librt")
else()
  message(WARNING "SUCCESS")
endif()
[14:55:55] ✔ jroelofs@galois build$ cmake ../ -DCMAKE_SYSTEM_NAME=iOS -GNinja
CMake Warning at CMakeLists.txt:12 (message):
  FAILURE: should not have found librt


-- Configuring done
-- Generating done
-- Build files have been written to: /Users/jroelofs/lrt_repro/build