On Thu, Sep 03, 2015 at 12:42:30PM -0600, Jeff Law wrote: > Note huge parts of combine are structured around the needs of processors > from the late 80s and early 90s. The canonical forms selected for those > processors may not be optimal for today's processors.
Or, more precisely, for the backends for those processors. Some of the canonicalisation rules are very inconvenient for some backends. > The problem (of course) is changing the canonical forms can be a ton of > work in both the backends as well as combine itself to ensure quality of > code doesn't regress. Yes exactly. Even more so than with other combine changes, before we do such changes we need to evaluate 1) what this changes, on what targets; and 2) how big the impact of that is. Without a proposed patch, all I can say is "most targets will need changes". > >>But the change from AND to zero_extract is already changing semantics... > > > >Oh? It is not supposed to! > Combine should never change semantics. It can change form and may > change what happens to "don't care" bits. But it should never change > visible semantics. And in the reverse transform (in change_zero_ext), it is hard to tell what those "don't care" bits are (so there are no such bits). Segher
