On Tue, May 3, 2016 at 3:26 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Tue, 3 May 2016, Richard Biener wrote: > >> On Tue, May 3, 2016 at 8:36 AM, Marc Glisse <marc.gli...@inria.fr> wrote: >>> >>> This removes the duplication. I also removed the case (A&B)&(A&C) which >>> is >>> handled by reassoc. And I need 2 NOP checks, for the case where @0 is a >>> constant (that couldn't happen before my patch because canonicalization >>> would put the constant as second operand). >> >> >> Nicely spotted. Not sure we want to delay (A&B)&(A&C) until re-assoc. We >> have >> many patterns that reassoc would also catch, like (A + CST) + CST or (A + >> B)- A, >> albeit reassoc only handles the unsigned cases. > > > (A&B)&A seems simple enough for match.pd, I thought (A&B)&(A&C) was starting > to be a bit specialized. I could easily add it back (making it work with | > at the same time), but then I am not convinced A&(B&C) is the best output. > If A&B or A&C have several uses, then (A&B)&C or B&(A&C) seem preferable > (and we would still have a transformation for (A&cst1)&cst2 so we wouldn't > lose in the case where B and C are constants). We may still end up having to > add some :s to the transformation I just touched.
Yeah, these are always tricky questions. Note that re-assoc won't handle the case with multi-use A&C or A&B. The only reason to care for the single-use case is when we change operations for the mixed operand cases. For the all-&| case there is only the (usual) consideration about SSA lifetime extension. So maybe it makes sense to split out the all-&| cases. Richard. > -- > Marc Glisse
