[Bug middle-end/78103] Failure to optimize with __builtin_clzl

["segher at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103

--- Comment #15 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #14)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Jakub Jelinek from comment #10)
> > > Unfortunately, it doesn't work for the #c0 testcase, after the combiner
> > > splitter kicks in, the combiner doesn't even try that 4 insn combination. 
> > 
> > It does for me?
> 
> But only in the unpatched gcc, no?

Yes, of course.

> For #c0 findLastSet I actually need to combine 5 original instructions,

[...]

That is not something we want to ever implement: 4 insns already is too
expensive unless we try only the simplest, and/or only very specific
combinations.

> and
> what I was hoping for is to first combine first 3 instructions into 2,
> 9, 10 -> 12 to get rid of the useless sign-extension,

You should be able to combine only 10 and 12 even, to a SImode xor followed
by the sign extension (may not work out wrt costs, but it isn't even tried).
Or, why is r86 DImode anyway?

> the value is known to
> be 0..63, so zero extension is fine, into 10 (bsr) and 12 (xor with zero
> extend), which is what the #c9 patch does.
> And then I was hoping 10, 12, 13 -> 14 would be attempted to be combined
> because 13 is mov of a constant.  But that doesn't happen because the 9, 10
> -> 12 combination with the #c9 patch throws away the 12 -> 10 LOG_LINKS and
> doesn't add a new one, even when 10 is a setter of a fresh new pseudo and 12
> is the only use of that pseudo.

This is only safe if it *is* a new pseudo, and even then, you need to prevent
getting stuck somehow.

insn 10 is the most problematic things here btw, having the same pseudo as
input and as output (it is not the unique setter either).  This happens in
expand already, probably a machine pattern that forgets to create new
registers where it should?