[RFC] Removing PSTL (original) (raw)

I propose to remove the PSTL top-level project in the monorepo: llvm-project/pstl at main · llvm/llvm-project · GitHub

This topic was raised by @ldionne during one of the monthly maintainer meetups as the project does not seem to have panned out as planned and the top-level repo appears to be effectively dead in-tree. The last functional change was in May 2022.

It’s unclear to what extent libstdc++ folks are using the in-tree PSTL repo, if at all. So there may be a reason to retain it, but we still need a maintenance plan in that case. There is a WG21 meeting happening next week in Sofia, so I am posting this RFC now to give folks interested in the topic some time to think about it and have discussions next week to determine whether there’s a long-term strategy for maintaining this project or whether it can be removed.

CC @philnik @mordante @jwakely @rarutyun for awareness

jwakely June 11, 2025, 1:33pm 2

We’re not really. There are no changes in the llvm code that we would need to sync with, because nobody’s changing the llvm code. If anything it just gives me more work to do, duplicating bug reports to llvm and to oneDPL, e.g.:

I’ve also reported a number of issues to llvm which I think are already fixed in oneDPL (and in GCC’s copy of pstl), and they don’t get any attention, even when I send a pull request to fix it.

I think libstdc++ should just sync from the oneDPL version of pstl, and cut out the llvm copy from the process.

Hmm… this would be unfortunate. Our in-tree repo provides us with some experimentation/extension space to the PSTL, and its just a shame that none have really panned out.

That said, it seems reasonable that anyone seriously interested in doing something like could always start by doing a re-integration of it instead (or submitting said code to the ‘upstream’).

ldionne June 16, 2025, 1:18pm 4

I support the removal. For additional context, two main things happened since the PSTL was added to the llvm monorepo.

First, we realized that using the public API provided in pstl/ was going to be very challenging, since libc++ uses numerous annotations and conventions in its code. For example, the way we annotate functions to control visibility, the ABI tag that we apply to many functions, our pushing and popping of macros in translation units, etc. Furthermore, the benefit of trying to reuse the public API is not that large. While there are a lot of declarations (a few per algorithm), the real difficulty is implementing the dispatching mechanism and the actual backends, not the “front end”. This observation reduced the incentive for reusing the code form pstl/.

Second, we met with various folks who were interested in eventually running PSTL algorithms on GPUs. They raised concerns about the customization point system provided in pstl/ and mentioned that they needed more flexibility, specifically the ability to customize arbitrary algorithms and redefine their own “computational basis”.

As a result, we decided to depart from the original direction of reusing the pstl/ code and started working on a different dispatching system, where we have about 35% of the public APIs implemented. Note that this direction does not preclude the use of oneDPL from libc++ – a oneDPL backend could be implemented pretty directly but we’d still be using libc++'s own dispatching mechanism on top (which doesn’t require the pstl/ code since we’d use oneDPL as an “external dependency”).

Since there is no current or planned future use of the code under pstl/, I think it makes sense to remove it and clear out some confusion.