On Sat, Aug 25, 2012 at 9:40 PM, Ian Lance Taylor <i...@google.com> wrote:
>>>> 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 <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.
>>>
>>> Maybe mention that the default is to allow all combinations for
>>> which a pattern match? And that the reason to disallow them can
>>> be that they're known to result in suboptimal code? Or other
>>> reasons.
>>
>> Something like this perhaps:
>>
>> /* Returns true if the combined insn should be rejected
>> for some reason. */
>> DEFHOOK
>> (reject_combined_insn,
>> "Take an instruction in @var{insn} and return @code{true} if the instruction\
>> should be rejected as a combination of two or more instructions. The\
>> default is to accept all instructions.",
>> bool, (rtx insn),
>> hook_bool_rtx_false)
>>
>>> I don't think it should be mentioned that it can be used to stop
>>> invalid code to be generated; that'd just be encouraging
>>> covering up bugs in reload. (Using it to simplify the port may
>>> be valid.)
>>
>> Please note that there is no mention of the specific purpose of this
>> hook. x86 uses it to counter a specific reload problem, but this is
>> just hook _implementation_ detail.
>
>
> What if we just add a global variable during_combine, and the insn
> predicates can check that variable? Then we wouldn't need a new
> target hook, one that seems slightly obscure to me.
No, in x86 case we need to look at operand constraints of the insn,
and we need to recognize and analyse the insn. This way, we can avoid
i.e. "ax_reg", "nonimm_ax_reg" and such register constraints.
Uros.
