This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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~
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]