This is the mail archive of the
mailing list for the GCC project.
Re: Operand Scan times
On Fri, Oct 19, 2007 at 02:00:07PM -0400, Andrew MacLeod wrote:
> Andrew Haley wrote:
> >I think you're missing the point, Andrew. A qsort() implementation
> >might pass a pointer to the same array element in p and q during
> >partitioning. In that case, u1 == u2. Your assert is wrong.
> ah, That would be a pretty lame implementation, comparing the same
> element is a clear waste of time :-) Is it actually triggering somewhere?
The OpenWatcom C library does something like this for some inputs to
... pick some value for 'i' here ...
tmp = array[i];
compare (&array[i-2], &tmp);
compare (&array[i-1], &tmp);
compare (&array[i-0], &tmp);
and this triggers gcc_assert().
> I'm certainly not attached to the assert, but it is too bad we will have
> to waste cycles on every single call to the comparison function to check
> for the 'equal' case, which by rights should never happen.
The extra check happens only when we would have aborted. It also appears
to me that the return value calculation is needlessly complicated. A simple
subtraction of the values is sufficient and faster on most CPUs. This is
what I'm using:
--- gcc/tree-ssa-operands.c (revision 129371)
+++ gcc/tree-ssa-operands.c (working copy)
@@ -220,9 +220,9 @@ operand_build_cmp (const void *p, const
/* We want to sort in ascending order. They can never be equal. */
- gcc_assert (u1 != u2);
+ gcc_assert (u1 != u2 || e1 == e2);
- return (u1 > u2 ? 1 : -1);
+ return (u1 - u2);
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year