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: Jeff Law <law at redhat dot com>
- To: Graham Stott <graham dot stott at btinternet dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, rdsandiford at googlemail dot com
- Date: Wed, 03 Jul 2013 11:48:29 -0600
- 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> <87ip0r1qwp dot fsf at talisman dot default>
On 07/03/13 11:42, Richard Sandiford wrote:
Yea, we ought to be reasonably good at detecting non-zero ranges in VRP
and eliminating the trap. Doing it that way may also expose weaknesses
in VRP which obviously we'd like to fix.
Graham Stott <firstname.lastname@example.org> writes:
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.