[Bug target/14255] i386 backend should be teached how to use divl

["wilson at specifixinc dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From wilson at specifixinc dot com  2004-02-25 03:08 -------
Subject: Re:  New: i386 backend should be teached
 how to use divl

bernie at develer dot com wrote:
> When dividing a 64bit integer by a 32bit integer,
> GCC promotes everything to 64bits and generates
> dumb code calling *both* __divdi3 and __moddi3.
> A single divl instruction would have sufficed.

It is more complicated than that.

The ISO C standard says that when you have 64b / 32b, the 32-bit value 
must be promoted to 64-bits, and we must perform a 64-bit operation 
yielding a 64-bit result.  If the user wants only a 32-bit result, then 
the 64-bit result is truncated to 32-bits.

Now we have the question of whether
	64b / 32b -> 32b result, 32b remainder
gives the same result as
	(32b) (64b / (64b) 32b)
for all possible input values.  I believe it doesn't, though I don't 
recall the details.  It is probably easier to prove this using 16b / 8b 
divides, where we can produce all values and check.  See the shorten 
code in build_binary_op in c-typeck.c for instance about another divide 
shortening problem.

Thus we can not easily generate the divl instruction directly.

If we are willing to diverge from the ISO C standard here, we could add 
an operation for this.  This would require adding new named patterns 
which are similar to the mulsidi3 patterns, except we would have 
divdisi3 or something like that.  This divergent behaviour would have to 
be enabled by an option.

We could provide a builtin (intrinsic) so that the user can generate the 
divl instruction is that is what they want.  Many architectures have an 
instruction like this, so this is generally useful.

If we have value range info for the operands, we might be able to prove 
that the two operations give the same result for this program.  I think 
the only inputs that fail are edge conditions like dividing by MIN_INT 
which are rare.  However, this requires some kind of value range 
tracking in the compiler.  I believe we have some now, but I don't know 
if it is good enough to help here.

Generating both the divide and modulo operations is stupid though.  We 
can perhaps fix that even if we can't generate the divl instruction.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14255