Re: [PATCH] SH: New define_split sh.md

["Naveen Sharma, Noida" <naveens at noida dot hcltech dot com>]

Joern Rennecke, October 23, 2003 8:31 PM Wrote:
> > Please let me know if you have some corner cases in mind.
> 
> I'm thinking just of the case where we have mostly EX 
> instructions and one
> short load.  In that case, the load is clearly superior to generating
> two more EX instructions.
> 
> In the cases where the splitter helps, do you generally see the loads
> clustered already when you'd do the split?  In that case, you could
> look at the type of the surrounding instructions.
> 
> Of course, a better long-term solution would be to have 
> scheduler-driven
> splitters, but in the mean time, looking at the surrounding insns
> seems the most viable way to check for this situation.

I tried this. Lookibng 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))]

The reason is, if we use get_attr_insn_class (), the 
enum members like INSN_CLASS_LS_GROUP are not available (because they
have not been processed yet).

Is there a better way out ? If not, We should probably go by 
the original patch.

Best Regards,
Naveen Sharma.