On Wed, 12 Oct 2016, Prathamesh Kulkarni wrote: > Hi, > I was having a look at PR71636 and added the following pattern to match.pd: > x & ((1U << b) - 1) -> x & ~(~0U << b) > However the transform is useful only if the target supports "andnot" > instruction. > As pointed out by Marc in PR for -march=core2, lhs generates worse > code than rhs, > so we shouldn't do the transform if target doesn't support andnot insn. > (perhaps we could do the reverse transform for target not supporting andnot?) > > However it seems andnot isn't a standard pattern name, so am not sure > how to check > if target supports andnot insn ?
There is no easy way - you can build RTL and run it through recog ... But generally on GIMPLE we do not want to apply such early target specific "optimization". Rather on GIMPLE we apply canonicalization and the above transform would be done by RTL expansion (or by a GIMPLE pass right before that). If you wanted to use match.pd for that we need to start thinking about how to handle target specific transforms that should only apply late -- for example by generating an alternate API from a separate .pd file or by adding sth similar to && reload_completed to patterns, say via doing at the end of match.pd (if (now_expanding_to_rtl) #include "target.pd" ) and have targets supply their own .pd file (where each pattern gets (if (now_expanding_to_rtl) ...) added). You'd have to supply empty target.pd or include tm.h and a new target macro specifying whether target.pd exists or not. Richard.
