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

[Andrew Pinski <pinskia at gmail dot com>]

On Thu, Aug 23, 2012 at 10:52 AM, Georg-Johann Lay <avr@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  <ubizjak@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.
>