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: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 30 Oct 2003 12:26:40 +0530
- Subject: Re: [PATCH] SH: New define_split sh.md
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.