home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / gnu / gcc / bug / 3136 < prev    next >
Encoding:
Text File  |  1993-01-08  |  2.2 KB  |  77 lines

  1. Newsgroups: gnu.gcc.bug
  2. Path: sparky!uunet!cis.ohio-state.edu!modcomp.COM!joe
  3. From: joe@modcomp.COM (Joe Korty)
  4. Subject: gcc-2.3.3: ++E vs E+=1
  5. Message-ID: <m0nA3bC-00002UC@rlxdev.modcomp.com>
  6. Sender: gnulists@ai.mit.edu
  7. Organization: GNUs Not Usenet
  8. Distribution: gnu
  9. Date: Thu, 7 Jan 1993 20:13:01 GMT
  10. Approved: bug-gcc@prep.ai.mit.edu
  11. Lines: 64
  12.  
  13. Gcc generates less efficient code for the `++E' construct than it does
  14. for the equivalent `E+=1', a suprising result given that the pre- and
  15. post-increment forms are intended to make it easier for compilers to
  16. find the most efficient code.  Below are some sample 88k assembly
  17. fragments illustrating the effect.  The inefficiency (I hesitate to
  18. call it a problem) seems to originate in the way expand_increment()
  19. converts a preincrement tree to rtl (done in a funny way in order to
  20. get around a nasty protect_from_queue() side effect in expand_binop()),
  21. and hence is likely to affect more than just the 88k.
  22.  
  23. Compiler options: -O.  Compilers tested: 2.2.2, 2.3.1, 2.3.3.  System:
  24. m88k-realix (a svr3 motorola delta box derivative; for C, equivalent to
  25. m88k-motorola).
  26.  
  27. We noticed this only because it came up in some critical sections of
  28. our code; for now, we have converted the most affected statements to the
  29. equivalent assignment form.
  30.  
  31. ; f(sp)
  32. ; register short *sp;
  33. ; {
  34. ;  return ++(*sp);
  35. ; }
  36. _f:
  37.     ld.hu     r9,r0,r2
  38.     addu     r9,r9,1
  39.     st.h     r9,r0,r2
  40.     ld.h     r2,r0,r2  ; why the extra load?  should be an ext r2,r9,16<0>
  41.     jmp     r1
  42.  
  43.  
  44. ; g(sp)
  45. ; register short *sp;
  46. ; {
  47. ;   return (*sp)+=1;
  48. ; }
  49. _g:
  50.     or     r9,r0,r2
  51.     ld.hu     r2,r0,r9
  52.     addu     r2,r2,1
  53.     st.h     r2,r0,r9
  54.     jmp.n     r1
  55.     ext     r2,r2,16<0>
  56.  
  57. Any changes to gcc will also have to pass the following stress test.
  58. This causes emit_queue() to be called at the appropriately nasty point,
  59. and will result in subtly defective assembly code if the fix is invalid
  60. (naturally, I have not been able to find an efficient, valid fix to
  61. expand_increment() that passes this test).
  62.  
  63. f(sp)
  64. short *sp;
  65. {
  66.   return (++(*sp)) >= 0 ? g(sp) : 0;
  67. }
  68.  
  69. -- 
  70. Joe Korty,  REAL/IX Operating Systems
  71.  
  72. MODCOMP, an AEG Company            Telephone: (305) 977-1820
  73. 1650 West McNab Road            Fax:       (305) 977-1638
  74. P.O. Box 6099                E-mail:       uunet!modcomp!joe
  75. Ft. Lauderdale, FL 33309-1088
  76.  
  77.