On 06/25/16 10:43 PM, Erik de Castro Lopo wrote:
First off, this code is horrible to read and work on. The recent commits
are the first of what I hope is a massive clean up of this code.
lvqcl wrote:
>So if I understand things correctly, the current meaning of --(en|dis)able-sse
is:
>
>on Linux:
> --enable-sse:
> add -msse2 to the compiler switches
> do not test SSE OS support (assume that SSE is supported)
> --disable-sse:
> do NOT add -msse2
> test SSE OS support
>
>on other OSes:
> --enable-sse:
> add -msse2 to the compiler switches
> test SSE OS support (why?)
> --disable-sse:
> do NOT add -msse2
> test SSE OS support
>
>It's a bit contradictory: why test whether *BSD etc support SSE or not
>but at the same time allow compiler to use SSE/SSE2 unconditionally?
Yes, that needs to be fixed. I think the way it works on Linux makes
the most sense.
Doesn't SSE support imply SSE2+ support? The problem is that the OS has
to preserve the XMMS registers when doing a context switch. Once the
kernel is preserving the XMMS registers, I'd assume that all SSEx
instructions should work.
I have a '96 install of an OS, it has been upgraded until end of life,
and it handles SSE4+ instructions fine even though the instruction set
was released more recently then the last kernel.
Dave
_______________________________________________
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
