HaohaiWen wrote: > Thanks for the updated example! > > To explain what I meant in first comment using this example: We would perform > the transform https://alive2.llvm.org/ce/z/nllcB_, which does not depend at > all on how `%yx` is constructed, and whether there is any way to form the > `fshl` separately. If the `%yx` is appropriately constructed, the `fshl` can > be removed (https://alive2.llvm.org/ce/z/B_KOwv, another missing transform). > > Is this not a viable approach? Is there a concern here that generating both > fshl and bitreverse may be non-profitable for targets without bitreverse? Or > maybe supporting this makes the matching too expensive?
It's absolutely a feasible solution. Solution1: First optimize bitreverse then eliminate redundant fshl: https://alive2.llvm.org/ce/z/g_gWf3 This requires a) First teach collectBitParts to not only search until unknown opcode, but also try to use itself as root. b) Teach recognizeBSwapOrBitReverseIdiom to recognize bit pattern [n/2 -1, ..., 1, 0, n-1, n-2, .... n/2]. Then insert bitreverse and fshl. c) Teach instcombine to remove redundant fshl if opposite concat exists. This requires to scan def-users chains. To eliminate fshl, we also need to scan def->users chains. Solution2: First optimize or to fshl then optimize bitreverse: https://alive2.llvm.org/ce/z/WbzJVo https://github.com/llvm/llvm-project/pull/68502 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits