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

[Uros Bizjak]

On Sat, Aug 25, 2012 at 6:54 PM, Georg-Johann Lay <avr@gjlay.de> wrote:

>> Hello!
>>
>> v2 patch differences:
>> - moves hook description text to target.def
>> - fixes error path to clear clobbers, as expected by recog_for_combine
>> callers
>>
>> 2012-08-25  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 {,-m32}.
>>
>> OK for mainline?

>
> Just a question:
>
> avr.md could use this hook instead of the
> combine_pseudo_register_operand predicate in order to reject
> hard registers in some insns before register allocation.

> Is it valid to use INSN_CODE (insn)?  E.g. compare it against
> CODE_FOR_foo for a light-wight detection of the insn in
> the backend?

No, you have to call recog (note, not recog_memoized) first to get new
INSN_CODE. Note, that clobbers are added to the pattern in
recog_for_combine just before the call to the hook.

> And may recod_data.operands[] et al. be used then?

No, you HAVE to set INSN_CODE of the tested insn and call extract_insn
(insn) in the backend.

> Or is garbage therein and the backend has to call recog on its own?

There is garbage, backend has to do its own call to recog.

> The hook documentation could make this clear.

The hook in fact just receives combined insn, and recog_for_combine
restores insn to original state before exit. Backend can use this insn
as a test site for its (possibly destructive) checks. I agree that the
documentation should say that backend does not need to restore insn to
its original state.

> In the case where the answer to the above questions is "no",
> i.e. the hook runs prior to recog: Why is this so?

Instruction with all its clobbers added to the pattern has not yet
been fully recognized. Backed in free to re-recognize the insn to
obtain its INSN_UID for checks or further processing.

> The performance gain is just minimal and sensible INSN_CODE
> and recog_data can make it considerably more easy to filter
> (u)nwanted insns instead of rewriting parts of recog in the
> hook.

What you are referring to is x86 version of the hook that has to check
for hard register constraints and check passed regs to these
constraints. Where do you see reimplementation of recog?

Uros.