On Tue, Jan 12, 2016 at 6:10 AM, Jeff Law <l...@redhat.com> wrote: > 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.
But those don't feed another bit operation, right? Thus we'd like to see ((a & b) & c) & 1, not ((a & b) & 1) & c? It sounds like the instructions are designed to feed conditionals (aka CC consuming ops)? Richard. > > > Jeff
