On Mon, Jan 21, 2019 at 2:46 AM Andi Kleen <a...@linux.intel.com> wrote: > > Wojciech Muła <wojciech_m...@poczta.onet.pl> writes: > > > > The main concern is if it's a proper approach? Seems that to match > > other logic functions, like "a & b | c", a separate pattern is required. > > Since an argument can be either negated or not, and we can use three > > logic ops (or, and, xor) there would be 72 patterns. So maybe a new > > optimization pass would be easier to create and maintain? (Just a silly > > guess.) > > Yes that's not scalable.
You can use code iterators for the logic ops so only need to explicitely write down the not variants. > > > > I'd be grateful for any comments and advice. > > Maybe you could write it in the simplifier pattern language > and then generate a suitable builtin. Using an UNSPEC and machine-reorg might also be an option... > See https://gcc.gnu.org/onlinedocs/gccint/Match-and-Simplify.html > > However the problem is that this may affect other optimizations > because it happens too early. e.g. the compiler would also need > to learn to constant propagate the new builtin, and understand > its side effects, which might affect a lot of places. > > So a custom compiler patch that runs late may be better. > Or perhaps some extension of the simplifier that does it. > > I looked at this at some point for PCMP*STR* which are similarly > powerful instructions that could potentially replace a lot of > others. > > -Andi
