This is the mail archive of the
mailing list for the GCC project.
Re: MIPS elimate trap-if-zero instruction if possible for divisions
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Graham Stott <graham dot stott at btinternet dot com>
- Cc: "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 03 Jul 2013 18:42:30 +0100
- Subject: Re: MIPS elimate trap-if-zero instruction if possible for divisions
- References: <1372858960 dot 88297 dot YahooMailNeo at web87404 dot mail dot ir2 dot yahoo dot com>
Graham Stott <email@example.com> writes:
> Hi Richard,
> This patch attemps to elimate the TEQ instruction div DIV/MOD instructions
> if possible (i.e the numerator is known to be non-zero)
> I have introduced and seperated UNSPEC UNSPEC_SET_HILO_NOTRAP
> which is generation by a peephole2 when the trap is known not to be required.
> The peephole's work by checking for a REG_EQUAL or/REG_EQUIV on the
> instruction which sets the numerator for the DIV/MOD this doesn't catch all
> possible cases but does catch the common cases where ths numerator is
> set set in a insn immediately preceeding the DIV/MOD.
Nice idea, but TBH, I think I'd prefer to expose the trap code at expand time
and let the rtl optimisers try to remove it. I can't remember any correctness
reason why that wouldn't work. I think the only reason we don't do it yet is
because (before gimple) there was a preference for keeping the division as
a unit during early rtl optimisations.