On Fri, Jul 09, 2021 at 08:43:59AM +0200, Richard Biener wrote: > I wonder if there's a way to query the target what modes the doloop > pattern can handle (not being too familiar with the doloop code).
You can look what modes are allowed for operand 0 of doloop_end, perhaps? Although that is a define_expand, not a define_insn, so it is hard to introspect. > Why do you need to do any checks besides the new type being able to > represent all IV values? The original doloop IV will never wrap > (OTOH if niter is U*_MAX then we compute niter + 1 which will become > zero ... I suppose the doloop might still do the correct thing here > but it also still will with a IV with larger type). doloop_valid_p guarantees it is simple and doesn't wrap. > I'd have expected sth like > > ntype = lang_hooks.types.type_for_mode (word_mode, TYPE_UNSIGNED > (ntype)); > > thus the decision made using a mode - which is also why I wonder > if there's a way to query the target for this. As you say, > it _may_ be fast, so better check (somehow). Almost all targets just use Pmode, but there is no such guarantee I think, and esp. some targets that do not have machine insns for this (but want to generate different code for this anyway) can do pretty much anything. Maybe using just Pmode here is good enough though? Segher
