[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #13 from steven at gcc dot gnu dot org 2006-02-11 11:27 --- GCC 4.2 gives me the code with eax again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #14 from steven at gcc dot gnu dot org 2006-02-11 11:36 --- And so does GCC 4.1. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #15 from hjl at lucon dot org 2006-02-11 20:17 --- FYI, -march=i686 turns on -mtune=generic32 in 4.2, while it turns on -mtune=pentiumpro in gcc 4.0 and 4.1. I backported the patch to 4.1: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-03 01:04 --- This is actually invalid as nothing happens for -Os case so what you are seeing is just an atrifact. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #5 from dann at godzilla dot ics dot uci dot edu 2005-11-03 01:27 --- (In reply to comment #4) This is actually invalid as nothing happens for -Os case so what you are seeing is just an atrifact. Sorry but this explanation for marking the PR invalid does not make sense. The code in question is generated using -O2 not -Os. IMO the observation in comment #3 is important, and there should be some explanation for it. -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-03 01:39 --- The use of ax vs cx will not matter in the real world. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-03 01:42 --- Remember if you care about code size use -Os. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #8 from dann at godzilla dot ics dot uci dot edu 2005-11-03 02:12 --- (In reply to comment #6) The use of ax vs cx will not matter in the real world. This is from a real world program (xterm) and it seems to matter, when using eax the code is smaller. Are you sure that the fact that eax is not used does not cover some other problem? Are the free registers picked at random for peepholes? It might be the case that 4.0 was just using eax by chance, but that does not mean the PR should be dismissed as invalid without understanding the underlying problem. -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-03 02:15 --- Have you tested the speed? As I said I really doubt it makes a real world change in terms of speed. This is different from code size. If you want it smaller use -Os or -march=pentium3 (as i686 is faster when splitting up the complex instructions). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #10 from dann at godzilla dot ics dot uci dot edu 2005-11-03 02:34 --- (In reply to comment #9) Have you tested the speed? As I said I really doubt it makes a real world change in terms of speed. This is different from code size. I am not sure what kind of answer you expect here. Speed and code size are not disjoint. Think about I-cache and I-TLB misses. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-03 02:40 --- (In reply to comment #10) I am not sure what kind of answer you expect here. Speed and code size are not disjoint. Think about I-cache and I-TLB misses. But again who is using an pentiumpro machine any more. People who really care about preformance in code really should be tunning for their machine. Xterm is not a good example of a program which really needs more speed. Also you are going to get a lot of Icache missed anyways as the machine is going to be switching between processes more offten than actually doing anything with this instruction. Now if you can prove that using -march=pentium3 (or 4 depending on your target) will be worse then just maybe. But otherwise this is invalid. Yes most distros defaultly compile for pentiumpro (i686) but that is not GCC's fault as this is actually faster for the pentumpro. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
[Bug rtl-optimization/23523] peephole2 causes code size on i686
--- Comment #12 from dann at godzilla dot ics dot uci dot edu 2005-11-03 07:51 --- (In reply to comment #11) (In reply to comment #10) I am not sure what kind of answer you expect here. Speed and code size are not disjoint. Think about I-cache and I-TLB misses. But again who is using an pentiumpro machine any more. People who really care The code generated -march=pentium3 or -march=pentium-m generate the same code. If you want to close this bug please address the technical issues about peepholes in comment #8. -- dann at godzilla dot ics dot uci dot edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23523
