On 01/11/2016 03:32 AM, Richard Biener wrote:
Yeah, reassoc is largely about canonicalization.
Plus doing it in TER is almost certainly more complex than getting it right
in reassoc to begin with.
I guess canonicalizing differently is ok but you'll still create
((a & b) & 1) & c then if you only change the above place.
What's best for that expression would depend on factors like whether or
not the target can exploit ILP. ie (a & b) & (1 & c) exposes more
parallelism while (((a & b) & c) & 1) is not good for parallelism, but
does expose the bit test.
reassoc currently generates ((a & 1) & b) & c which is dreadful as
there's no ILP or chance of creating a bit test. My patch shuffles
things around, but still doesn't expose the ILP or bit test in the 4
operand case. Based on the comments in reassoc, it didn't seem like the
author thought anything beyond the 3-operand case was worth handling.
So my patch just handles the 3-operand case.
So I'm not sure what pattern the backend is looking for?
It just wants the constant last in the sequence. That exposes bit
clear, set, flip, test, etc idioms.
Jeff
