1 |
On Fri, 2006-07-07 at 17:46 +0200, Kevin F. Quinn wrote: |
2 |
> On Fri, 7 Jul 2006 16:20:08 +0200 |
3 |
> Danny van Dyk <kugelfang@g.o> wrote: |
4 |
|
5 |
> Diego's proposal essentially generates CPU_SUBMODEL automatically from |
6 |
> CFLAGS - which could be the default behaviour if CPU_SUBMODEL is not |
7 |
> set. That way we have the best of both worlds; people who are happy to |
8 |
> let the system determine the configure options from the compiler |
9 |
> architecture can do so, those who want to control things in more detail |
10 |
> can do that as well. |
11 |
> |
12 |
|
13 |
I snipped your proposal, which I will reread better later on, but sounds |
14 |
not too bad if the glimpse was true. |
15 |
|
16 |
The big issue with Diego's proposal though that most of us for x86 have |
17 |
issues, is that you tie configure time optimisations that in theory |
18 |
should be good with most compilers, with gcc's potshots that may or may |
19 |
not be good. Sure, you might get away with it these days, because |
20 |
either bad stuff are filtered, or patched away, but it really is |
21 |
essentially not the same thing. |
22 |
|
23 |
I might for example with gcc-4.1.1 rather want gcc to do all |
24 |
optimization, as it does a better job than the coders do, but with 3.4.6 |
25 |
gcc that sucks at sse2 (ok, apparently this should be fixed with patches |
26 |
Mike backported, but still), I want what the developer coded mmx/sse |
27 |
code. |
28 |
|
29 |
The other side of it as well, is for new cpu's you might have to disable |
30 |
custom configure enabled mmx/sse/etc in general, as they break with the |
31 |
code (think when p4 was released). |
32 |
|
33 |
Sure, maybe adding auto detecting for USE="mmx sse sse2 etc" if they are |
34 |
not -mmx/-sse/etc can be a cool feature, but that is totally different. |
35 |
|
36 |
Hopefully that was clear - if not, point out what I should try to |
37 |
elaborate on. |
38 |
|
39 |
|
40 |
-- |
41 |
Martin Schlemmer |