1 |
On Fri, 2006-07-07 at 05:31 -0700, Brian Harring wrote: |
2 |
> On Fri, Jul 07, 2006 at 02:24:49PM +0200, Martin Schlemmer wrote: |
3 |
> > On Fri, 2006-07-07 at 02:08 +0200, Diego 'Flameeyes' Pettenò wrote: |
4 |
> > > On Friday 07 July 2006 01:54, Ciaran McCreesh wrote: |
5 |
> > > > | No, we never spent years telling them not to use your so-called |
6 |
> > > > | "CFLAGS hacks" that are rather a proper usage of what the compiler |
7 |
> > > > | gives you. |
8 |
> > > > Wrong. We did. |
9 |
> > > Then you were wrong. I could have spent time explaining them when they make |
10 |
> > > sense and why they don't in their usecases. If you did, well, then you really |
11 |
> > > need to know better what you do because you seem to me pretty confused |
12 |
> > > yourself, and I feel pity for you. |
13 |
> > > |
14 |
> > |
15 |
> > Yes, we did. Were we wrong? Out of a purest point of view ... maybe. |
16 |
> > The problem was though that earlier gcc's was very bad at generating |
17 |
> > sse/sse2, and sometimes mmx code. |
18 |
> > |
19 |
> > Users being what they are though (ricers should say it all), they |
20 |
> > enabled every flag that sounded like it could make their old box two |
21 |
> > times faster. This included -msse, -msse2, etc. Which quite frankly |
22 |
> > produced bad code in many cases. So we told the users to not add any |
23 |
> > -m* flags, and let gcc do its job with the proper -march. |
24 |
> > |
25 |
> > So yeah, I can see that general use flags for cpu features might become |
26 |
> > more tedious with the many new modules of processors out there, but to |
27 |
> > say handle it by adding -msse, etc to CFLAGS, will surely if not on |
28 |
> > gcc4, but then on gcc3 systems just ask for trouble. |
29 |
> > |
30 |
> > And yes, I know you are saying that that is not exactly what you are |
31 |
> > proposing, but the users will see it as a clear passport to stick all |
32 |
> > those nice sounding flags just right back in, and then it will be too |
33 |
> > late to tell them its not proper thing to do when the bugs start |
34 |
> > flooding in. |
35 |
> |
36 |
> Dumb question, but what really blocks them from doing that now for |
37 |
> x86 (for example)? |
38 |
> |
39 |
> Yes, can't enable certain flags for non x86/x86_64 arches, but the con |
40 |
> you're pointing at exists now for the most part. |
41 |
> |
42 |
|
43 |
I thought it was obvious, but apparently I overrated my writing |
44 |
skills :/ |
45 |
|
46 |
Anyhow, because now we can say 'don't do that!', or just close the bug |
47 |
as INVALID. If not, you can still try it, but the user might say we |
48 |
told him to enable sse/whatever like that. |
49 |
|
50 |
Also, as Luca stated, USE=mmx/sse/sse2/etc means that you enable |
51 |
tailored mmx/sse/whatever code, that should be working fine, as it was |
52 |
not gcc doing some shot in the dark at optimising, where if its |
53 |
enveloped with the CFLAGS, you cannot disable broken gcc optimisations, |
54 |
but enabled mmx/sse/whatever that should work on those older gcc's. |
55 |
|
56 |
|
57 |
-- |
58 |
Martin Schlemmer |