Skip to content

[cpullvm] Add polly to the list of LLVM projects to build#84

Merged
jonathonpenix merged 1 commit intoqualcomm-softwarefrom
users/jpenix/polly
Jan 27, 2026
Merged

[cpullvm] Add polly to the list of LLVM projects to build#84
jonathonpenix merged 1 commit intoqualcomm-softwarefrom
users/jpenix/polly

Conversation

@jonathonpenix
Copy link
Copy Markdown
Contributor

@jonathonpenix jonathonpenix commented Jan 23, 2026

In our past releases, it seems we stripped out the extra polly libs (libPolly.so, PollyISL, etc.) so omit those from distribution here as well.

@jonathonpenix jonathonpenix changed the title Add polly to the list of LLVM projects to build [cpullvm] Add polly to the list of LLVM projects to build Jan 23, 2026
@jonathonpenix jonathonpenix force-pushed the users/jpenix/refactor_arm_baseline branch from bd065ed to 16a10d5 Compare January 23, 2026 07:41
@apazos
Copy link
Copy Markdown
Contributor

apazos commented Jan 23, 2026

@efriedma-quic can you please comment on the extra polly libs (libPolly.so, PollyISL, etc.)

@chrisj-quic
Copy link
Copy Markdown

chrisj-quic commented Jan 24, 2026 •
edited
Loading

@jonathonpenix The changes LGTM

efriedma-quic
efriedma-quic approved these changes Jan 24, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

@efriedma-quic efriedma-quic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the right way to build polly. LGTM

@jonathonpenix jonathonpenix force-pushed the users/jpenix/refactor_arm_baseline branch from 16a10d5 to 6594921 Compare January 26, 2026 22:36
@apazos
Copy link
Copy Markdown
Contributor

apazos commented Jan 26, 2026

LGTM, you can rebase and merge.
Thanks @efriedma-quic for the feedback.

@jonathonpenix jonathonpenix force-pushed the users/jpenix/refactor_arm_baseline branch from 6594921 to 24d3723 Compare January 27, 2026 00:16
Base automatically changed from users/jpenix/refactor_arm_baseline to qualcomm-software January 27, 2026 00:34
@jonathonpenix
[cpullvm] Add polly to the list of LLVM projects to build
4ed4e62 
In our past releases, it seems we stripped out the extra polly libs
(libPolly.so, PollyISL, etc.) so omit those from distribution here
as well.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
@jonathonpenix jonathonpenix merged commit d51510d into qualcomm-software Jan 27, 2026
6 of 7 checks passed
@jonathonpenix jonathonpenix deleted the users/jpenix/polly branch January 27, 2026 00:37
jonathonpenix added a commit to jonathonpenix/cpullvm-toolchain that referenced this pull request Feb 1, 2026
@jonathonpenix
[cpullvm] Add polly to the list of LLVM projects to build (qualcomm#84)
bc305d2 
In our past releases, it seems we stripped out the extra polly libs
(libPolly.so, PollyISL, etc.) so omit those from distribution here
as well.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit d51510d)
jonathonpenix added a commit that referenced this pull request Feb 2, 2026
@jonathonpenix @zhaoshiz
[cpullvm] Bring mainline commits to the branch (#117)
f3d8f9f 
* Remove the ELD patch since it's merged upstream (#86)

The same change was merged in ELD upsteam:
qualcomm/eld@2cd8790

Signed-off-by: Zhaoshi Zheng <zhaoshiz@qti.qualcomm.com>
Co-authored-by: Zhaoshi Zheng <zhaoshiz@qti.qualcomm.com>
(cherry picked from commit bf0b9d9)

* [cpullvm] Remove upstream github workflows/utilities (#82)

As we brought in more commits, we've brought in more upstream workflows
again. Prune these as they are either clutter (in that they don't run
or do anything meaningful in our repository) or noisy (things start to
run but fail in our repo for unrelated reasons, or are just generally
irrelevant for the kinds of changes we can make in this repo).

So, clean these up again.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit 7283ad8)

* [cpullvm] Refactor using framework from ATfE (#83)

This is a big refactor of our initial cpullvm to use/follow how ATfE [1]
is organized/built.

Our motivation for heading in this direction is based on a few things:
- Generally, we don't want to make direct changes to the various repos
  we use (we'll use a copy from upstream and apply temporary and limited
  patches on top where needed).
- We need to support a reasonable amount of variants across multiple
  third-party libcs, with multilib support. We also want it to be
  relatively easy for outside individuals to be able to add their own
  variants for experimentation, etc.
- We have to support a diverse set of host platforms for our toolchain.
- We'd like to work towards enabling additional baremetal testing
  (compiler-rt, libc++) in a way that scales with our variants as per
  above. Additionally, we'd like to expand our ability to do
  toolchain-level testing/validation.

The ATfE approach seems to offer a reasonable framework for each of these.
Additionally, there's some prior art in this direction with ex: Zephyr's
LLVM SDK. So, let's use this as a launching point to hopefully reduce
the amount of groundwork we need to (re)do.

Note that the builds this produces isn't 1:1 with our current cpullvm
builds--MUSL variants, eld support, Linux configs, etc. will be added
in subsequent PRs.

Basically all the code added here is directly pulled from ATfE with some
editorializing and removing of features, etc. that we do not need or need
additional work and so are omitted for now. For reference, I was working
off a version of ATfE at [2] with [3] additionally cherry-picked.

Notable omissions from ATfE include:
- newlib/llvm-libc. llvm-libc might be interesting for us eventually, but
  we aren't using it for now. We do not want to support newlib.
- Shared header optimizations. We might want to re-introduce this, but
  for now it requires a bit of fixup for RISC-V so is omitted.
- Toolchain-testing/samples. We should reintroduce something like this, but
  this requires additional work. Revisit later.

[1] https://github.com/arm/arm-toolchain/tree/arm-software/arm-software/embedded
[2] arm/arm-toolchain@05b72a9
[3] arm/arm-toolchain@cb069eb

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit 4ff4312)

* [cpullvm] Add polly to the list of LLVM projects to build (#84)

In our past releases, it seems we stripped out the extra polly libs
(libPolly.so, PollyISL, etc.) so omit those from distribution here
as well.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit d51510d)

* [cpullvm] Integrate eld into cpullvm (#88)

We're adding a few patches here. For each, there are open issues and PRs in
eld--these are included as patches just to unblock further development while
the PRs are finalized. Overview of the patches:
- Currently, eld is missing some of the cmake scaffolding needed for use with
  LLVM_DISTRIBUTION_COMPONENTS. This is tracked in [1].
- A patch is added to fix ELDExpected.test. This is tracked in [2].
- The cmake that installs eld's symlinks breaks under CPack. This is tracked
  in [3].

There's a few other notable things here:
- check-eld will now be run when check-all is run
- I think more work will be needed to make it possible to run ex: compiler-rt
  and libc++ tests with eld. I briefly tried and the first issue seemed to be
  that libraries/dependencies weren't ordered in an eld/bfd-friendly way.
  There might be more issues. Leave this as future work.
- eld isn't integrated with xfails.py. I think this is best as there
  shouldn't be failures for any of our variants (and, IIUC, this is
  analogous to non-clang/compiler-rt/libc/libc++ tests).

[1] qualcomm/eld#693
[2] qualcomm/eld#710
[3] qualcomm/eld#737

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit bf45bb0)

* [cpullvm] Add baseline musl-embedded support, configs (#89)

This covers only the basic Arm/AArch64 configs that we added in our initial
cpullvm prototype. RISC-V configs will never be added and the various
"subvariants" (standalone, uselock, etc.) will be added in a subsequent
patch.

Also, build this as part of our precheckin as this is still a fairly core
component of our toolchain--long term we can revisit this. I also think the
current setup is a bit wasteful in that we build the tools twice, but ccache
should make this quick I guess--we can revisit this later.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit f9c5a38)

* [cpullvm] Add initial RISC-V support, baseline configs (#90)

This covers only our Zephyr-targeted RISC-V configs for now. Our RISC-V
configs with thread/TLS/atomic support disabled will be added in subsequent
patches.

Note that there's a bit of weirdness here with QEMU and running picolibc
tests--picolibc's `run-riscv` script tries to narrow down the enabled
extensions to only those present in the ELF file under test. I didn't
try replicating that here so we're losing some test coverage (if
unsupported instructions are generated). But:

- It isn't clear to me that picolibc's support is complete in this
  regard when quickly checking the enabled-by-default extensions for
  the cpus we use
- Presumably this will also be an issue for compiler-rt, libcxx, etc.
  so we probably want a non-picolibc-specific way of handling this in
  the long run
- Not using `run-riscv` gives us better multi-platform support
- I think we should be able to turn on/off extensions via `QEMU_CPU`
  in the per-variant .json file. So as we add configs that need
  not-enabled-by-default extensions, we still have a way to handle
  those.

So, punt on this for now and we can hopefully come up with a more ideal
way of handling this down the line.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit bbe5af1)

* [cpullvm] Add picolibc equivalents of our musl-embedded configs (#91)

In theory this way people using the musl configs have a (relatively) direct
equivalent that they can try out before we fully deprecate/remove musl.

The pacret configs both have tests disabled for picolibc as there are
test failures/faults--these need to be investigated at some point.

Note also that the shared musl/picolibc variant scheme here might fall apart
once we add a) musl subvariants (use-locks, etc.) and b) non-TLS/thread/atomic
picolibc variants as their multilib custom flags might start to diverge. But,
I think that is an issue best sorted out later/separately

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit 8491b9f)

* [cpullvm][Github] Prevent qcom-preflight-checks from running on forks (#95)

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit 8663869)

* [cpullvm] Add tests to check our multilib works with 'c' implication rules (#100)

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit c47162d)

* [cpullvm][Github] Restore our old nightly workflows (#101)

I removed these in [1] forgetting that that meant that the workflows
can't be triggered anymore, even from the branch.

Restore only the nightly configs and not the actual build scripts--I think
this should be sufficient for enabling nightly testing on the branch (I'm
hoping the actual build scripts that are invoked are the ones on the branch,
*not* the ones on qualcomm-software.

I also removed the scheduled runs for now as this is essentially
restricted to the 22.x branch at this point (and, these should be
updated/removed soon).

[1] 4ff4312

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit 981c064)

* [cpullvm] Don't ignore fails in the test script (#102)

Long term, ignoring fails and dumping the .xml might be better if we process
the results and have a convenient way of being alerted to issues. But, we
don't. And, for now, having the build outright fail in precheckins, etc. is
helpful. So, remove the `--ignore-fails` and xml output flags.

While here, also rename a few things in the precheckin to make it more
clear what is running/going on.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit 57b5f92)

* [cpullvm] Enable x86 target support and build against libstdc++ (#104)

The x86 change is largely just to enable additional testing and reach
parity with our past releases.

The libstdc++ change has a few motivations:
- Work around test failures when enabling x86 when building against libc++
  that use libunwind.
- This should hopefully be a better experience for most of our expected Linux
  users (on something close to Ubuntu 22+) in that they shouldn't have to
  additionally source libc++ to run the toolchain.

Long term, we'd like to head towards building/packaging a libc++ built from
the same sources, but that's a next step.

x86 support is disabled in eld for now as there are test failures when
building/testing on native AArch64 machines. This can be re-enabled when
qualcomm/eld#764 is resolved.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit d50b57c)

* [cpullvm] Expand usages of 'musl' to 'musl-embedded'. NFCI (#109)

I thought there were some sharp edges around '-' in variable names [1][2]
in cmake so originally I tried to avoid this sort of thing when adding
musl-embedded support. But, based on [3] I think this is actually fine for
what we do (and experimentally things seem to be working as expected). We're
getting ready to add upstream musl as a dependency for our linux configs,
so the shorthand 'musl' to refer to musl-embedded needs to change. Just use
'musl-embedded' in full to make things as clear as possible.

[1] https://cmake.org/cmake/help/book/mastering-cmake/chapter/Writing%20CMakeLists%20Files.html#variables
[2] https://gitlab.kitware.com/cmake/cmake/-/issues/23075
[3] https://cmake.org/cmake/help/v3.20/manual/cmake-language.7.html#variables

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit a52e093)

* [cpullvm] Move qualcomm-software/embedded/* to qualcomm-software/. NFCI (#110)

The embedded folder isn't a helpful distinction--as we start to add Linux
libraries, we want both Linux and embedded to be part of the same project.
As such, I think it makes more sense to have them at the same "level" in
our folder.

To prepare for this, move everything out of qualcomm-software/embedded into
qualcomm-software.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit 61f1e17)

* [cpullvm] Integrate Linux builds into our refactored workflow (#111)

For now, this just brings back our old build_linux_runtimes.sh script with a
few minor changes and improvements. This isn't ideal, but it is going to
take more time to neatly integrate Linux builds with how embedded works. So,
use this as a stopgap for now.

Notable changes to build_linux_runtimes.sh since it last appeared:
* The script no longer installs directly into the toolchain. It now
  assembles things into a temporary layout that we can then use in CMake.
* Similarly, the script now uses -resource dir to create and use a temporary
  resource dir rather than installing into the toolchain directly.
* Upstream musl is now a dependency like musl-embedded, etc. (it can
  be patched). Note that the Linux headers still are not.
* There's a bug fix where we were passing an empty target into the
  libc++ build. I'm surprised that hasn't caused us any failures.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit 430a571)

* [cpullvm] Add AArch64 Linux build to our premerge builds (#115)

There's dependencies that need to be sorted out in the AArch64 builder
(meson, etc.). So for now, just disable building the runtimes on AArch64
and do not run any tests that require the runtimes. build/test_no_runtimes.sh
should be deleted once this is resolved.

Also add an EXTRA_CMAKE_ARGS passthrough in our scripts--this is helpful
even when working locally to pass in extra options.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit c8470a9)

* [cpullvm] Add nightly workflow (#116)

This covers Windows x64/AArch64 and Linux x64/AArch64.

Make this workflow_dispatch-able only (and not scheduled) as we have
scheduled workflow_dispatch-ed runs.

For now, all Windows configs and AArch64 Linux are built and packaged
without runtimes. We'll address this in subsequent PRs.

Also, there's (I think) dependencies that need sorting out/are missing when
I started porting from our old build.ps1. Disable tests for now to unblock
other work and we'll come back to this.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
(cherry picked from commit 0a8801f)

* [cpullvm] Refactor cleanup for our branch

Now that we're brining the refactor on the branch, let's do a few things:
* Point eld to the 22 release branch
* Enable the rebase-specific premerge checks against the release branch
* Remove old nightly workflows now that they have been broken by the
  refactor and (mostly) replaced.

Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>

---------

Signed-off-by: Zhaoshi Zheng <zhaoshiz@qti.qualcomm.com>
Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
Signed-off-by: Jonathon Penix <jpenix@qti.qualcomm.com>
Co-authored-by: Zhaoshi Zheng <zhaoshiz@quicinc.com>
Co-authored-by: Zhaoshi Zheng <zhaoshiz@qti.qualcomm.com>
jonathonpenix added a commit to jonathonpenix/cpullvm-toolchain that referenced this pull request Feb 2, 2026
@jonathonpenix
[cpullvm] Add polly to the list of LLVM projects to build (qualcomm#84)
f1cd904 
In our past releases, it seems we stripped out the extra polly libs
(libPolly.so, PollyISL, etc.) so omit those from distribution here
as well.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit d51510d)
jonathonpenix added a commit that referenced this pull request Feb 2, 2026
@jonathonpenix
[cpullvm] Add polly to the list of LLVM projects to build (#84)
342ee1a 
In our past releases, it seems we stripped out the extra polly libs
(libPolly.so, PollyISL, etc.) so omit those from distribution here
as well.

Signed-off-by: Jonathon Penix <jpenix@quicinc.com>
(cherry picked from commit d51510d)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@apazos apazos apazos approved these changes

@efriedma-quic efriedma-quic efriedma-quic approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@jonathonpenix @apazos @chrisj-quic @efriedma-quic