Re: [PATCH v8 6/6] elf: Optimize _dl_new_hash in dl-new-hash.h

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 17/05/2022 00:58, Alexander Monakov wrote:
>> I did explain; I am not comfortable with controlling instruction scheduling in
>> that manner for generic code because it assumes more about underlying
>> processor pipelines and instruction sequences than we typically do in generic
>> code.  It has nothing to do with portability. Adhemerval raised the question
>> about whether this ought to be done in gcc instead, which I concurred with
>> too.
> 
> Thank you very much for the detailed response. Allow me to clear up what seems
> to be a technical misunderstanding here: this is not about instruction
> scheduling, but rather dependencies in the computations (I know Noah mentioned
> scheduling, but it's confusing especially in context of benchmarking for an
> out-of-order CPU).
> 
> I have shown how different variants have different chains of dependencies in
> this email: https://sourceware.org/pipermail/libc-alpha/2022-May/138495.html

Agreed, but again the latencies due to that dependency graph may have 
more or less impact depending on the architecture and eventually is 
linked to the code schedule, so the difference is academic IMO.

> The empty asms are used to prevent compiler reassociating 'h*32 + (h + c)'
> to '(h*32 + h) + c' which looks fine in isolation, but significantly changes
> the dependency graph in context of the whole loop.
> 
> There's nothing specific to the x86 architecture in this reasoning. On arm and
> aarch64 it's moot because they evaluate 'h*32 + h' in a single cycle, though.

That may well be true, but there are always architecture quirks to throw 
one off that may have been missed in testing or may turn up later.  Like 
I conceded before, it may well be that my concerns are unfounded and 
that gcc will generate the best code for all architectures with those 
barriers in place but that choice should be explicitly made based on 
benchmarks.

Siddhesh