[llvm-dev] Proposal: introduce dependency on abseil when building benchmarks

Mircea Trofin via llvm-dev llvm-dev at lists.llvm.org
Thu Oct 7 13:05:20 PDT 2021

On Thu, Oct 7, 2021 at 12:51 PM James Y Knight <jyknight at google.com> wrote:

> On Thu, Oct 7, 2021 at 11:40 AM Renato Golin via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> On Thu, 30 Sept 2021 at 18:08, Mircea Trofin via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>> Abseil has some requirements
>>> <https://abseil.io/docs/cpp/platforms/platforms#:~:text=Abseil%20requires%20a%20code%20base,14%20through%20C%2B%2B20).>
>>> that may not perfectly match those of the impacted projects. For example,
>>> abseil stopped supporting Ubuntu 14.04 before its TLS.
>> The list of supported platforms is *definitely* too small for LLVM users.
>> Half of their support is "best effort", which really isn't going to cut it
>> once we forcefully depend on it.
>> We definitely run benchmarks on X86_64, Arm32/64, MIPS, PowerPC (Linux,
>> Mac and Windows on a mix of those), and there are probably people running
>> on SystemZ, RISCV and other less known architectures.
> I think this isn't actually as big a deal as it sounds. The primary
> difference between "supported" and "best-effort" is whether they have
> working CI for that platform. Furthermore, many unlisted platforms do work.
> In practice, abseil has a history of accepting patches to add portability
> for "unsupported" platforms.
> E.g. to take two examples:
> https://github.com/abseil/abseil-cpp/pull/1021 adding support for AIX
> https://github.com/abseil/abseil-cpp/pull/904 adding support for Linux on
> HPPA, Alpha, IA64, and SH.
>> What is your plan for all the other platforms where abseil isn't
>> supported?
> The plan should simply be: submit patches if it's broken on an
> architecture or OS that someone cares about.
> Old versions of the toolchains is a different matter, however -- Abseil's
> general promise is to support an old release of a C++ compiler for 5 years
> after it has been superseded by a newer version. And supporting old
> compilers tends to be a significant burden, so unlike porting to a new CPU
> or OS, *that* isn't simply a "patches welcome" situation -- there would
> have to be a compelling case made that preserving support for an compiler
> older than that was important enough to be worth the hassle.
> See also: https://abseil.io/blog/20201001-platforms
(Just to make sure this aspect isn't lost) all of this matters *if* we want
to start updating the copies of `benchmark` in llvm / llvm-test-suite from
upstream `benchmark`. It's all moot if we are OK to continue, indefinitely,
with maintaining our own copies. (to echo Renato - this topic of how we
want to consume `benchmark` is a question for the folks that care about
running those benchmarks. I'll try find & add more to to/cc in a bit)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/713f64c0/attachment.html>

More information about the llvm-dev mailing list