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

[Georg-Johann Lay]

Uros Bizjak schrieb:
> 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?

And may recod_data.operands[] et al. be used then?
Or is garbage therein and the backend has to call recog on its own?

The hook documentation could make this clear.

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

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.

Johann