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

[Alexander Monakov]

On Mon, 16 May 2022, Adhemerval Zanella via Libc-alpha wrote:

> >> How hard would to make compiler to make this very optimization? I raised 
> >> this on weekly call because more and more it seems that tuning computation
> >> dependencies for loop tuning seems to be more a compiler job than libc's
> >> (although this not a blocker, but we have multiple smalls micro-optimizations
> >> in the past that turned in dead code due compiler catching up).
> > 
> > Sorry, since you're responding to a discussion about multiply-add, it's unclear
> > to me which optimization you mean. Is your question about choosing which
> > sequence of additions has shorter cross-iteration chain?
> 
> Indeed I was not clear, I mean the reply to [1] where you explain why 
> you have suggested the asm to prevent compiler reassociating.  
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2022-May/138794.html

I think it's pretty hard, you'd have to decompose 'h*33' into '(h<<5)+h'
in the reassociation pass, notice that it's a part of addition chain that
feeds the phi node for 'h', and based on that select a specific
association variant (all to shave off one cycle per iteration). To me it
looks like an optimization just for this exact scenario. And then you
need to "hope" that no other pass undoes this transformation.

It would be quite some nontrivial code in the compiler, when the alternative is
getting a guaranteed outcome for any compiler by adding an empty asm statement
in a loop that iterates thousands of times on every process startup.

Alexander