This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] [PATCH][PR tree-optimization/64910] Fix reassociation of binary bitwise operations with 3 operands


On 01/12/2016 08:11 AM, Richard Biener wrote:
On Tue, Jan 12, 2016 at 6:10 AM, Jeff Law <law@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)?
At the gimple level they could feed a conditional, or be part of a series of ops on an SSA_NAME that eventually gets stored to memory, etc. At the RTL level they'll feed CC consumers and bit manipulations of pseudos or memory.

For the 3-op case, we always want the constant last. For the 4-op case it's less clear. Though ((a & b) & c) & 1 is certainly better than ((a & b) & 1) & c.

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]