This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] SH: New define_split sh.md
- From: "Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>
- To: Richard Henderson <rth at redhat dot com>, Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 30 Oct 2003 18:12:59 +0530
- Subject: Re: [PATCH] SH: New define_split sh.md
Richard Henderson [rth@redhat.com], October 30, 2003 1:17 PM
> > I tried this. Looking for surrounding insns in the conditions
> > for splitter doesn't looks clean.
> >
> > (define_split
> > [(set (match_operand:SI 0 "arith_reg_operand" "r")
> > (match_operand:SI 1 "const_int_operand" "i"))]
> > "TARGET_SH4 && INTVAL (operands[1]) >= 128 &&
> reload_completed" <-- Here
> > [(set (match_dup 0) (match_dup 0))]
>
> In this case it's better to use peep2 instead of splitters.
Yes, Indeed!!
Actually, that introduces one more issue.
HAVE_peephole2 is undefined for SH at the moment.
So, introducing it increases a compile time overhead
as an extra pass will run on the insn-chain.
I think I need to measure that.
And we also need to consider:
1. Although we avoid a possible stall by looking at the
surrounding insns, we have the literal pool.
The case, where we need to insert a branch around the literal pool,
will make decision of *not* synthesizing the literal earlier,
look bad.
2. The peephole is a local picture.
3. The benchmarking that I did suggests that splitting
is a win, even if, surrounding insns are not considered.
However, I cannot claim that is always the case.
4. I also agree with Joern's concern on cases where doing the
split may be bad.
Any suggestion, on how much weight to put on each pro/con?
Thanks and Best Regards,
Naveen Sharma.
> r~
>