On Thu, Aug 23, 2012 at 10:52 AM, Georg-Johann Lay <a...@gjlay.de> wrote: > Uros Bizjak wrote: >> Hello! >> >> This patch introduces TARGET_REJECT_COMBINED_INSN target hook, so >> targets are able to reject combinations of two or more insns. The hook >> is called from recog_for_combine, so it is the target that has the >> final say on the combined insn. > > Hi, > > great place for a hook, it was missing, IMO. > > Just a note: Wouldn't it be good to have a hook that may transform > a pattern to a new one and return that to combine? > > Your reject_combined_insn would be a special case, e.g. return > NULL_RTX. > > Sometimes recog_for_combine fails (resp. recog fails) because > recog_for_combine does not try all possible transformations and > therefore recog then fails because there is no combine pattern.
Or just better yet improve recog_for_combine. I was planing on doing that for some cases dealing with zero_extract. Thanks, Andrew Pinski > > However, there may be a pattern that does exactly the same thing > but is written down differently. The backend then could try to > canonicalize the pattern before it goes into recog. > > An other question is: > > I always wondered if it is possible to transform code like > > (set (reg:SI 0) > (ior:SI (reg SI:1) > (reg SI:2))) > > or more complicated, combined patterns to a different pattern > if there is some additional knowledge. > > For example, a backend may have an insn that can do the > combined operation efficiently, but only if reg2 is a > boolean value (0 or 1). > > Currently you will have to write a combine pattern like > > > (set (reg:SI 0) > (ior:SI (reg SI:1) > (and:SI (reg SI:2) > (const_int 0)))) > > and/or > > (set (reg:SI 0) > (ior:SI (reg SI:1) > (zero_extract:SI (reg:SI 2) > (const_int 1) > (const_int x))))) > > and/or > > (set (reg:SI 0) > (ior:SI (reg SI:1) > (and:SI (lshiftrt:SI (reg SI:2) > (const_int x)) > (const_int 1)))) > > You can imagine that it is really tedious to write > down all these patterns and describe their rtx_costs. > > If the targed had a way to say "this transformation is > okay under the condition X" that would be great. > > combine collects many information on the values like > ranges and set/unset bits, but that information cannot > be used for matching/rejecting on the insn level, > e.g. in an insn predicate or insn condition. > > A Hook would do this: > > - If the pattern is to be rejected, return NULL_RTX. > > - If the pattern is fine, return it (recog will run on it). > > - If the target can make use of additional information, > it might return the origonal pattern or reject it. > Here again, recog runs on the pattern (provided the hook > returned non-NULL). > > - The hook may canonicalize the pattern and cook a new one. > In that case the backend is responsible for a correct > transformation. Also in this case recog runs on the > returned pattern. > > Another use case could be to fold away an UNSPEC. > > From the hook perspective, it's no additional work: > Just call the hook from recog_for_combine, receive the > pattern back from the backend, check for NULL_RTX and > then run recog. > > Thanks, > > Johann > > >> This target hook will be used in a follow-up x86 patch that rejects >> instructions where hard registers don't fit into operand register >> constraint. >> >> 2012-08-23 Uros Bizjak <ubiz...@gmail.com> >> >> * target.def (reject_combined_insn): New target hook. >> * doc/tm.texi.in (TARGET_REJECT_COMBINED_INSN): New hook. >> * doc/tm.texi: Regenerated. >> * combine.c (recog_for_combine): Call targetm.reject_combined_insn >> to allow targets to reject combined insn. >> >> Bootstrapped and regression tested on x86_64-pc-linux-gnu. >> >> OK for mainline? >> >> Uros. >
