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

[Mircea Trofin via llvm-dev]

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>