[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2013-05-17 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359

Uroš Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-05/msg00941.htm
   ||l
 Resolution|--- |FIXED
   Target Milestone|--- |4.7.4

--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
Implemented for 4.7.4, 4.8.1 and mainline by:

Author: uros
Date: Thu May 16 19:53:36 2013
New Revision: 198987

URL: http://gcc.gnu.org/viewcvs?rev=198987root=gccview=rev
Log:
PR target/45359
PR target/46396
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
VIA/Centaur processors and determine their cache parameters
using detect_caches_amd.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/driver-i386.c

Author: uros
Date: Thu May 16 21:41:26 2013
New Revision: 198989

URL: http://gcc.gnu.org/viewcvs?rev=198989root=gccview=rev
Log:
* config/i386/driver-i386.c (host_detect_local_cpu): Determine
cache parameters using detect_caches_amd also for CYRIX,
NSC and TM2 signatures.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/driver-i386.c

Author: uros
Date: Fri May 17 15:06:36 2013
New Revision: 199017

URL: http://gcc.gnu.org/viewcvs?rev=199017root=gccview=rev
Log:
Backport from mainline
2013-05-16  Uros Bizjak  ubiz...@gmail.com

* config/i386/driver-i386.c (host_detect_local_cpu): Determine
cache parameters using detect_caches_amd also for CYRIX,
NSC and TM2 signatures.

2013-05-16  Uros Bizjak  ubiz...@gmail.com
Dzianis Kahanovich  maha...@eu.by

PR target/45359
PR target/46396
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
VIA/Centaur processors and determine their cache parameters
using detect_caches_amd.

2013-05-15  Uros Bizjak  ubiz...@gmail.com

* config/i386/i386.c (ix86_option_override_internal): Update
processor_alias_table for missing PTA_PRFCHW and PTA_FXSR flags.  Add
PTA_POPCNT to corei7 entry. Do not enable SSE prefetch on
non-SSE 3dNow! targets.  Enable TARGET_PRFCHW for TARGET_3DNOW targets.
* config/i386/i386.md (prefetch): Enable for TARGET_PRFCHW instead
of TARGET_3DNOW.
(*prefetch_3dnow): Enable for TARGET_PRFCHW only.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/i386/driver-i386.c
branches/gcc-4_8-branch/gcc/config/i386/i386.c
branches/gcc-4_8-branch/gcc/config/i386/i386.md

Author: uros
Date: Fri May 17 17:50:11 2013
New Revision: 199026

URL: http://gcc.gnu.org/viewcvs?rev=199026root=gccview=rev
Log:
Backport from mainline
2013-05-16  Uros Bizjak  ubiz...@gmail.com

* config/i386/driver-i386.c (host_detect_local_cpu): Determine
cache parameters using detect_caches_amd also for CYRIX,
NSC and TM2 signatures.

2013-05-16  Uros Bizjak  ubiz...@gmail.com
Dzianis Kahanovich  maha...@eu.by

PR target/45359
PR target/46396
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
VIA/Centaur processors and determine their cache parameters
using detect_caches_amd.

2013-05-15  Uros Bizjak  ubiz...@gmail.com

* config/i386/i386.c (ix86_option_override_internal): Add
PTA_POPCNT to corei7 entry.


Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/config/i386/driver-i386.c
branches/gcc-4_7-branch/gcc/config/i386/i386.c

[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2013-04-25 Thread linuxball at netscape dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359



linuxball at netscape dot net changed:



   What|Removed |Added



 CC||linuxball at netscape dot

   ||net



--- Comment #6 from linuxball at netscape dot net 2013-04-25 19:07:45 UTC ---

I reconfirm this bug using gcc 4.6.3-1ubuntu5 in Ubuntu 12.04 to compile stuff

optimized for VIA C7-D Esther processor. Still the same issue:



Using -march=native 



1) still chooses -march=pentium-m -mtune=generic (ignoring the sse3 capability)

2) will not detect the L1 and L2 cache parameters



IMHO, the centaur2.patch suggested by Dzianis Kahanovich is a good fix. Why

hasn't it found its way into the official gcc?



Best regards and thanks to Dzianis for his contribution



linuxball


[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2010-11-18 Thread mahatma at eu dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359

Dzianis Kahanovich mahatma at eu dot by changed:

   What|Removed |Added

  Attachment #22306|0   |1
is obsolete||

--- Comment #5 from Dzianis Kahanovich mahatma at eu dot by 2010-11-18 
13:05:51 UTC ---
Created attachment 22445
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22445
centaur2.patch

Compatibility with GNU assembler -mtune set (#40171).


[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2010-11-07 Thread mahatma at eu dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359

Dzianis Kahanovich mahatma at eu dot by changed:

   What|Removed |Added

  Attachment #0|0   |1
is obsolete||

--- Comment #4 from Dzianis Kahanovich mahatma at eu dot by 2010-11-07 
10:47:13 UTC ---
Created attachment 22306
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22306
centaur.patch

Just cleanup (c3-2). -mtune not passed to assembler, then -mtune vs. NOPL
(by Gentoo Wiki) is not useful. May be -Wa,-mtune=generic or -Wa,, but not
here...


[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2010-11-01 Thread mahatma at eu dot by
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359

--- Comment #3 from Dzianis Kahanovich mahatma at eu dot by 2010-11-01 
13:21:40 UTC ---
Created attachment 0
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=0
native VIA/CentaurHauls

(In reply to comment #1)
 Why do you think it's a poor choice?

This is regression after PR target/44046. Previous behaviour was:
sse3 - -march=prescott -mtune=generic, now: sse3 - -march=pentium-m
-mtune=generic. This regression lose sse3 support for C-7 CPU. But in other
point, prescott as family-15 member, may be (or not) else scheduled, then
family-6 clone... Other source of problem - VIA/Centaur CPUs detecting as
Intel vendor. I believe, Intel support have own reason to make choice sse3 -
pentium-m and lose this sse3, then I suggest to forget this behaviour and add
native VIA/CentaurHauls support code. There are 3 point of detection:
1) vendor signature;
2) cache detection: according to Linux kernel code,  detect_caches_amd
behaviour is not vendor-specific and used in kernel also for any x86_64,
VIA/Centaur, Transmeta and Cyrix family-5/model-5, but I have no exotic CPUs
exclude VIA C-7 in my notebook to test other vendors;
3) model detection - C-7 will be -march=prescott -mtune=core2 (FIXME if pure
prescott is better!), also may be fixed c3-2 -mtune=c3 selection (Gentoo Wiki
suggest -mtune=generic or -march=c3 to avoid NOPL for some models, but I try to
not use variable generic).


[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2010-08-24 Thread opod at nic-nac-project dot org


--- Comment #2 from opod at nic-nac-project dot org  2010-08-24 18:58 
---
(In reply to comment #1)
The processor clearly supports SSE3 so perhaps -march=prescott would be better
instead of -march=pentium-m. I also assumed that -march=pentium-m implies
-mfpmath=387 but it does not seem to apply (or matter). Finally, -march=native
on my laptop picks up L1 and L2 cache sizes as --params which does not happen
for the VIA C7. Just for reference, it is reported as 

Cache info
 L1 Instruction cache: 64KB, 4-way associative, 1 lines per tag, line size=64
bytes.
 L1 Data cache: 64KB 4-way associative, 1 lines per tag, line size=64 bytes.
 L2 (on CPU) cache: 128KB 10-way associative, 1 lines per tag, line size=64
bytes.

HTH


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359



[Bug target/45359] poor -march=native choices for VIA C7 Esther processors

2010-08-23 Thread rguenth at gcc dot gnu dot org


--- Comment #1 from rguenth at gcc dot gnu dot org  2010-08-23 20:17 ---
Why do you think it's a poor choice?


-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45359