llvm dev - Oct 2021 - Proposal: introduce dependency on abseil when building benchmarks

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/ec410a5b/attachment.html>

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>

On Thu, 7 Oct 2021 at 20:51, James Y Knight <jyknight at google.com>
wrote:
> The plan should simply be: submit patches if it's broken on an
> architecture or OS that someone cares about.
>
This only works if the people who currently run those benchmarks in LLVM
can continue running them _before_ submitting patches.

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.
>
Because it supports clang, it should be fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/16e03214/attachment.html>