This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: more stormy16 opcodes


Usual integral promotions means that there is no way to express mixed mode
divides in the C language.  So an expression like
        (short)((long)(x) / (short)(y))
must be implemented as a long / long divide, and then we can cast the long
result to short.

Gcc has had mixed mode extending multiplies for a long time, e.g. mulsidi3.
However, gcc has never had mixed mode shortening divides, and there is no
code to try to recognize them.  If you add a pattern for them, they will only
match for C if you have a expander/splitter that generates them, or if you
have a builtin that generates them.  Presumably other languages that can
express this operation could generate them easily, if we had named patterns
for them, but we don't.

There is code in gcc to shorten operations.  Given an operation on longs whose
result is casted to short, if there is an equivalent operation on shorts, then
we will try to generate that operation.  Unfortunately, this does not work
for signed divides, because mathematically
        (short)((long) (x) / (long) (y))
is not the same as
        ((short) (x) / (short) (y))
An easy way to see this is to consider the result of dividing SHORT_MIN by
-1.  In the first expression, it is (long)SHORT_MAX+1, which is then
explicitly converted to SHORT_MIN.  In the second expression, we have a
divide overflow, which may give different results on different hardware,
including a trap on some hardware.  So the second expression is clearly not
equivalent to the first, and we can not shorten signed divides unless the
divisor is a constant whose value is known to be not -1.  We can shorten
unsigned divides however, as they do not have this problem.

Therefore, if you have mixed mode divides and/or short divides, you must
add builtin functions if you want to be able to generate them from C input.

This topic has come up in other threads recently.  See for instance
        http://gcc.gnu.org/ml/gcc/2002-10/msg00516.html
        http://gcc.gnu.org/ml/gcc/2002-10/msg00521.html

I think the concept of divide builtin functions for xstorm16 should be
accepted.  The only question should be whether there are any design or
style problems that need to be fixed.

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]