[PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

[Uros Bizjak]

On Thu, Aug 23, 2012 at 7:52 PM, Georg-Johann Lay <avr@gjlay.de> wrote:

>> 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.
>
> 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.
>
> 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.

This is the job for simplify_rtx, it should canonicalize insn into
some "standard" form.
>
> 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.

I believe that this is the job for combine_simplify_rtx, so the
combined RTX gets simplified to some standard form. Your example above
has its counterpart in x86 zero-extended addresses, where we have a
nice collection of SUBREGs, ANDs and ZERO_EXTENDs in all possible
combinations.

> Another use case could be to fold away an UNSPEC.

No, I don't agree here. I'd recommend to avoid UNSPECs as much as
possible, and a precise description of the insn should be used from
the beginning.

> 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.

Your proposed simplifications should be implemented as standard RTX
simplifications, but given the fact than nobody bothered with it
suggest that they are not that critical. From my experience, two or
maybe three patterns fits all cases.

Uros.