Re: EQNTOTT Vectors of 16 bit Numbers

Andy "Krazy" Glew, <glew@ichips.intel.com> writes:


> Myself, I *want* compilers to get as good as possible; I *want*
> compilers to be able to do all of the dirty tricks that assembly
> language programmers are used to doing, so that said assembly
> language programmers can spend time working on useful things rather
> than tuning code.


Yes, we certainly want compilers to improve. However, there were a
number of serious problems with EQNTOTT optimization which caused it
to be deleted from SPEC95. In particular, some compilers would
generate extremely efficient code for EQNTOTT, but would generate
incorrect code for programs that looked too much like EQNTOTT, but
were not EQNTOTT.


For example, one source-to-source optimizer performed the following
transformation.


The EQNTOTT hot spot looks something like:


short aa, bb;
for (...)
{
aa = ...;
bb = ...;
if (aa == 2) aa = 0;
if (bb == 2) bb = 0;
if (aa == bb) continue;
...
}


It has been observed that aa and bb are often equal, and the performance
can be increased if the third IF statement is propagated in front of
the other IF statements, yielding:


short aa, bb;
for (...)
{
aa = ...;
bb = ...;
if (aa == bb) continue;
if (aa == 2) aa = 0;
if (bb == 2) bb = 0;
if (aa == bb) continue;
...
}


However, this translation can not be applied to the following example
(which looks extremely similar to EQNTOTT, but isn't, and gets caught
in the EQNTOTT optimizers net).


unsigned short aa;
short bb;
for (...)
{
aa = ...;
bb = ...;
if (aa == 2) aa = -1;
if (bb == 2) bb = -1;
if (aa == bb) continue;
...
}


If ints and shorts are not the same size, then propagating the third
IF statement in front of the first two IF statements is not correct,
since an unsigned short 2 is equal to a short 2, but an unsigned
short -1 is not equal to a short -1.


Regards,
Christopher Glaeser
Nullstone Corporation
--

Return to the comp.compilers page.
Search the comp.compilers archives again.