[Scummvm-devel] Wii & Gamecube (resp. PowerPC) vs. unaligned memory access

yotam barnoy yotambarnoy at gmail.com
Mon May 9 15:19:32 CEST 2011


> Indeed, that is exactly the kind of nasty bugs I am afraid of; hence my desire to make the current READ_UINT* versions for GCC 4.x the default for GCC 4.x, *even* if supposedly we don't need to worry about unaligned access...

OK that sounds like a good idea.

>>
>> The reason not to remove -fno-strict-aliasing is performance.
>
> I assume you meant "not to add -fno-strict-aliasing" resp. "not to remove -fstrict-aliasing" and will reply to the following accordingly :)

Yep my mistake :)

>
>> At least, last time we talked about aliasing, I suggested using
>> -fno-strict-aliasing, and everyone replied that it would cause serious
>> slowdown.
>
> Hm, I can't seem to find that in the email archive nor do I recall it (the latter means nothing, just that my memory is as leaky as usual *sigh*). Can you point me to where that was discussed? Would be interesting to know and record (this time in a comment in endian.h, maybe) on which systems specifically there were noticeable or even "serious" slowdowns.
>

OK that might be my memory playing tricks on me as well. It's also
possible that I got that impression from reading a bunch of material
on the web at the time. I seem to remember some ScummVM folks telling
me it wasn't a good idea to use -fno-strict-aliasing after I submitted
it, but I can't remember when or who, and it's not really that
important.

I can't really say that I noticed slowdown on the PSP in the brief
period that I had no-strict-aliasing on, but again that was a while
ago. The Linux kernel compiles with no-strict-aliasing, so it can't be
that bad. I think it's more of a psychological thing -- since I've
been hunting for optimizations for so long, I can't bring myself to
say that it's ok to turn off a feature that is used for compiler
optimizations.

Yotam




More information about the Scummvm-devel mailing list