Hi all, 

I reported from many people, that

"TAKEHIRO_IEEE754_HACK works fine and it's fast. kudos!"
"TAKEHIRO_IEEE754_HACK is fast, but does not work! shit!"

oops, why ?

I finally found the reason. that is caused by GCC's optimization method,
called "type based aliase detection"(http://gcc.gnu.org/news/alias.html).

TAKEHIRO_IEEE754_HACK is code like this

void quantize_xrpow(FLOAT8 xp[576], int pi[576], gr_info *cod_info)
{
    /* quantize on xr^(3/4) instead of xr */
    const FLOAT8 istep = IPOW20(cod_info->global_gain);

    int j;
    for (j = 576; j > 0; --j) {
        double x0 = istep * xp[0] + MAGIC_FLOAT;
        ((float*)pi)[0] = x0;
        ((float *)pi)[0] = (x0 + adj43asm[pi[0] - MAGIC_INT]);
        pi[0] -= MAGIC_INT;
    }
}

of cause, there are an alias between
        ((float *)pi)[0] = (x0 + adj43asm[pi[0] - MAGIC_INT]);
and
        pi[0] -= MAGIC_INT;
but the "type based aliase detection" falls to find this alias.

so the workaround answer is to compile it with -fno-strict-alias, which
disables this "type based aliase detection".
--- 
Takehiro TOMINAGA // may the source be with you!
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Reply via email to