On Fri, 6 Dec 2019, Marc Glisse wrote: > On Fri, 6 Dec 2019, Richard Biener wrote: > > >>> nop_convert sees that 'a' comes from a conversion, and only returns d > >>> (unlike 'convert?' which would try both a and d). > > Maybe I should have formulated it as: nop_convert works kind of like a > strip_nops. > > >> If use gets more and more we can make nop_convert a first class citizen and > >> allow a? Variant. > > One reason I did not specifically push for that is that nop_convert is seldom > the right condition. It is convenient because it is usually easy enough to > check that it is correct, but in most cases one of narrowing / zero-extension > / sign-extension also works. Still, it is better to handle just NOPs than no > conversion at all, so I guess making that easy is still good.
In my view nop_convert is useful to avoid cluttering the code with (if (tree_nop_conversion_p ...) checks that are even redundant when a (convert? ... is stripped away. > > Like the attached (need to adjust docs & rename some functions still) > > which generalizes > > [digit]? parsing. This allows you to write (nop_convert? ...) > > I guess once this is in, we should replace all (most?) 'nop_convert' with > 'nop_convert?' (and possibly a digit in some places) and remove the last > alternative in the definition of nop_convert. Yes, that was my thinking. > Although that will increase the code size. In case, we could still have both a > nop_convert and a strip_nop predicates. Just thinking: We should measure it, yes, I hope it won't be too bad ;) In theory making genmatch emitted code more like a graph rather than a tree (with shared leafs) might save us a bit here. > (match (nop_convert @0) > (convert @0) > (if (tree_nop_conversion_p (type, TREE_TYPE (@0))))) > (match (nop_convert @0) > (view_convert @0) > (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@0)) > && known_eq (TYPE_VECTOR_SUBPARTS (type), > TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0))) > && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE > && (@0)))))) > > (match (strip_nops @0) > (nop_convert? @0)) > > but that relies on the fact that when there is an optional operation, the > machinery first tries with the operation, and then without, the order matters. > Maybe being explicit on the priorities is safer > > (match (strip_nops @0) > (nop_convert @0)) > (match (strip_nops @0) > @0) Yeah, I don't think the above complexity is worth it. > > It works (generated files are unchanged), so I guess I'll push it > > after polishing. > > > > It also extends the 1/2/3 grouping to be able to group like (plus > > (nop_convert2? @0) (convert2? @1)) > > so either both will be present or none (meaning that when grouping you > > can choose the "cheaper" > > test for one in case you know the conversions will be the same). > > Nice. r279037. Richard.
