Uros Bizjak schrieb:
On Sat, Aug 25, 2012 at 6:54 PM, Georg-Johann Lay <a...@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 <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.
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?
I am thinking of how this new hook could be used in the avr backend.
For some reasons sign/zero source must not be a hard register at
combine time, but combine propagates hard registers into the
input operands. avr.md disallows that by a predicate:
(define_insn "extendqisi2"
[(set (match_operand:SI 0 "register_operand" "=r,r")
(sign_extend:SI
(match_operand:QI 1 "combine_pseudo_register_operand" "0,*r")))]
With valid data from recog the avr version of the hook would be
something like
if (icode == CODE_FOR_extendqihi2
|| icode == CODE_FOR_extendqipsi2
|| icode == CODE_FOR_extendqisi2
|| ...=
{
if (REGNO (recog_data[icode].operands[1]) < FIRST_PSEUDO_REGISTER)
return true;
}
without you have to look into the insn anatomy:
if (single_set (insn)
&& (SIGN_EXTEND == GET_CODE (SET_SRC (single_set (insn)))
|| ZERO_EXTEND == GET_CODE (SET_SRC (single_set (insn))))
&& REG_P (XEXP (SET_SRC (single_set (insn)), 0))
&& REGNO (XEXP (SET_SRC (single_set (insn)), 0))
< FIRST_PSEUDO_REGISTER)
{
return true;
}
for complex patterns this will turn to a recog-like XEXP orgy that
is hard to read and maintain. Ugly.
BTW: while I typed the lines above I find it more natural to
return "true" for good patterns and "false" for bad patterns
and not vice versa. But that's just a matter of taste.
Johann
