Adding AArch64 BOLT Buildbot and Improving Testing (original) (raw)

Hello BOLT community,

It’s been some time since we at Arm have been working on BOLT. There’s plenty of ongoing work, with more to come. One area we are focusing on is testing: pre-merge, post-merge, and extending end-to-end binary testing to improve coverage (i.e., the out-of-tree repo rafaelauler/bolt-tests). This post focuses on post-merge testing.

To that end, we’ve been running a Buildbot internally for a few months, and now it’s time to upstream it. I aim to have a public version up and running in the next few weeks, depending on the review process.

It’s been a while since the Buildbot code was updated, and changes in the llvm-project have degraded some of its functionality. I’ve taken this opportunity to introduce further changes to the BOLTBuilder, addressing current issues and adding improvements.

Below is a series of patches in llvm-zorg and llvm-project that I hope you’ll welcome and consider merging. More details are available in the individual PRs. The status column tracks progress.

On llvm-zorg:

This is a series of 7 Stacked Pull-Requests. They incrementally clean up and extend functionality, with the final patch adding our AArch64 Buildbot to the configuration.

Some internal stats of running this configuration. Out of the last 20 commits:

• Half of the tests were skipped as BOLT had no changes
• When BOLT had changes, checks took an average of ~5 minutes (min/max: 2 to 16 minutes). That is dependent on the patches of course.
• When there are no changes, checks complete in a few seconds

On llvm-project:

Two patches for improvements and features needed by the BOLT buildbot configuration.

Many thanks,
Paschalis

aaupov June 10, 2025, 5:07pm 2

Thank you for putting the effort into improving BOLT testing.

I’ll review these changes in a short order.

The existing buildbot still provides a useful signal: e.g. a recent breakage due to MC changes only affecting ARM Buildbot.

To avoid losing the signal during the migration, we can first migrate existing builders to a new worker (just add it under a new name, e.g. bolt-worker-armh-aarch64) and add builders incrementally along with fixes/improvements.

Let me know if that works, and we can move from there.

Hi Amir,

I’d really appreciate that, thanks in advance!
I can also give a quick rundown of the changes during ‘Office Hours’.

To avoid losing the signal during the migration, we can first migrate existing builders to a new worker (just add it under a new name, e.g. bolt-worker-armh-aarch64) and add builders incrementally along with fixes/improvements.

Sounds good. We can rename the worker and keep it around to make sure we don’t miss anything, and clean up as needed at the end. BTW, can you force a clean build on the bolt-aarch64-ubuntu-clang?