[build2] Fix build on older x86 and arm CPUs

[Norbert Lange]

2017-12-23 13:25 GMT+01:00 Boris Kolpackov <boris at codesynthesis.com>:
> Norbert Lange <nolange79 at gmail.com> writes:
>
>> Well, not on CPUs missing those ops, but thats only half the truth.
>> distros like debian support those old CPUs, means you have to be able to
>> generate code that works on those, even if everyone running dev-software
>> will have CPUs that fully support atomics (and gcc/llbatomic will
>> dynamically decide to use the instructions).
>
> I don't believe that decision is dynamic, i.e., at runtime. My understanding
> is that it's decided at compile-time based on the target CPU.

Its dynamic in the sense that often a mutex is only needed in some
cases, ex. not sufficiently aligned variables.

>
>
>> The warning/error should be just removed IMHO.
>
> The error is used to make sure we don't use anything non-lock-free on
> modern platforms. So a macro that basically says, "yes, I understand
> things won't be lock-free" is the way to go.

Again, why is this an issue, is there any measured performance implication?
Even if mutexes are added, they themself have an atomic variable as
first level and only lock on contention.
I would expect build2 will block on file-io and subprocesses all the
time, this ain`t exactly HPC.

If there is much contention to affect perfromance, you need to look at
what you are doing,
because heavy contention will hurt your modern systems aswell
(cache-eviction and -locking can take 100000s instructions)

Can't tell anything without analyzing your whole code, but there
usually is rarely a need to use atomics directly,
usually you are better served with higher abstractions like async-io
and job-queues.

Even if such a check makes sense, I would not put it into the mid of
production code (it does not affect functionality),
but check it during the configuration stage (or make a
conformance-test submodule as the first thing thats compiled).

>> Perf issues are something you deal with when you have concrete issues,
>> and if there is no support in the toolchain you WILL notice, but possibly
>> later when linking.
>
> Again, you are only thinking about GCC/libstdc++. For example, on Clang
> with libc++ things may just silently becomes non-lock-free (I actually
> don't know what Clang/libc++ do in this case). Same goes for MSVC.
>
>
>> I can live with passing in args/env-vars but I am not sure why this is
>> different to linking -lpthread which is just coded in.
>
> The difference with -lpthread is that (1) it is always needed (at least
> conceptually) and (2) it is available on all the modern platform/compiler/
> runtime combinations we care to target.

Its more common, but exactly the same issue: feature of the C++
library that needs non-portable commandline args for the compiler.
And if you want to get build2 into popular distros, you will either
need to get it running on all/most platform or neither build2 *nor
projects using it* will be available for the missing platforms.
The build system is either native or emulated, no "real"
cross-compiler involved.
>
>
>> is the aim for build2 to add featuretests like autotools/CMake?
>
> While we may still end up supporting something like this, at this stage
> we are trying hard to avoid it and instead base decisions like this
> on "static" information about compiler/target. So far it has been
> going[1] reasonably well.
>
> [1] https://stage.build2.org (see, for example, libmysqlclient for some
>     non-trivial buildfile).
>
> Boris

Norbert