[MPlayer-dev-eng] [PATCH] Disable optimizations when compiling with icc

[Reimar Doeffinger]

Hello,
On Sun, Jun 10, 2007 at 11:06:54AM +0000, Carl Eugen Hoyos wrote:
> Reimar Doeffinger <Reimar.Doeffinger <at> stud.uni-karlsruhe.de> writes:
[...]
> > I guess it will have weird effects with runtime cpudetection. Also a
> > MPlayer binary without asm optimization is IMO rather useless. And
> > lastly I think last time even some of the non-MMX/SSE/3DNOW asm would
> > not compile.
> 
> Could you give an example for something that possibly wouldn't work? I only
> tested xvmc, xvidix, xv, rtsp, wmv9dmo, ac3, aac, mp3, vc1, mpeg2, mpeg4 and
> avc, because that's what I typically use.

I meant that without asm optimization MPlayer is really, really slow. No
matter what you do. I don't think we such compile like that without
warning (someone might accidentially have the intel compiler in the
path, whatever). I don't remember which of the pure X86 asm would not
compile, I just _think_ that there was some...
I think there is some code that assumes that XMM registers aren't
modified in (short) non-asm blocks - that might already fail with some
gcc versions, and even more with intel compilers. But that's not too
relevant to this case I think.

> > IMO print a big warning that recommends using --target=generic-linux
> 
> How should target=generic-linux help? Would that deactivate optimizations in
> libswscale, liba52 and mp3lib?

It will just behave as if you were compiling MPlayer on some unknown
architecture. That means pure C code. It might be suboptimal because it
will also not set e.g. FAST_UNALIGNED.

> > that the user has to confirm. Since ICC is not really supported such a
> > message similar to the one for a certain older gcc version isn't a bad
> > idea (also since libmpeg2 probably still compiles but the result is broken).
> 
> How could this be tested? For me, it produces output that looks correct.

Just try playing any MPEG-2 file with libmpeg2. If you don't get loads
of funny looking colours it works.

> > I am also certain that all these "hacks" were not needed for version
> > 8.x, maybe it did not support asm() at all?
> 
> Sorry, I only tested 10.0

No problem.
While I think we should make building with different compilers simpler,
we shouldn't make it look like they are officially supported. Using them
still has major disadvantages as of now.

Greetings,
Reimar Doeffinger