Bug 13214 - GCJ uses surprsingly long to compile included example
Summary: GCJ uses surprsingly long to compile included example
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: compile-time-hog
Depends on:
Blocks:
 
Reported: 2003-11-28 11:18 UTC by oyvind.harboe
Modified: 2017-01-11 22:37 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-07-15 21:43:38

Attachments
Example file (528.10 KB, application/octet-stream)
2003-11-28 11:18 UTC, oyvind.harboe 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description oyvind.harboe 2003-11-28 11:18:02 UTC 
I have larger programs that compile much more quickly.

\thisiscool-gcc-3.4\gcc-3.4\bin\gcj   test.jar -o test --
main=com.cyviz.xyzmodem.StackImpl

Also there is an issue with the app, it runs fine w/JRE, but does not run when 
compile w/GCJ:

Exception in thread "main" java.lang.Error: US-ASCII (java.lang.ClassNotFoundExc
eption: gnu.gcj.convert.Output_ASCII not found in [file:.\, core:/])
   at 0x0097600e (Unknown Source)
   at 0x00976502 (Unknown Source)
   at 0x0097d2b4 (Unknown Source)
   at 0x00938027 (Unknown Source)
   at 0x009393d3 (Unknown Source)
   at 0x0093904e (Unknown Source)
   at 0x00938fac (Unknown Source)
   at 0x00938f55 (Unknown Source)
   at 0x00928177 (Unknown Source)
   at 0x009a8d6e (Unknown Source)
   at 0x009a2d50 (Unknown Source)
   at 0x00974727 (Unknown Source)
   at 0x00974807 (Unknown Source)
   at 0x004012ea (Unknown Source)
   at 0x00401209 (Unknown Source)
   at 0x00401234 (Unknown Source)
   at 0x7c5987e3 (Unknown Source)
Comment 1 oyvind.harboe 2003-11-28 11:18:41 UTC 
Created attachment 5223 [details]
Example file
Comment 2 Andrew Pinski 2003-11-28 17:58:23 UTC 
I can confirm this but it looks like there is a large number of code aka the middle-end is slow part.
The other problem is static linking does not work correctly there is a PR for that.
Comment 3 Andrew Pinski 2003-12-01 02:23:55 UTC 
On the tree-ssa the problem is cause a lot by the java front-end (but I have an older version of the 
tree-ssa aka without the fix for bytecode compiling).
Comment 4 Andrew Pinski 2004-04-27 14:04:30 UTC 
Back in the middle-end on the tree-ssa.  

Speeding up can happen by inlining rtx_alloc_stat for -O0 speedup.

For -O1 and above, inlining craph_edge would help a lot.

Putting these two functions in the headers and then declaring them as inline will help.
Comment 5 Andrew Pinski 2004-11-30 18:30:59 UTC 
 dominator optimization:  17.89 ( 7%) usr   0.88 ( 4%) sys  21.48 ( 6%) wall
 expand                :  13.68 ( 5%) usr   0.81 ( 3%) sys  18.65 ( 6%) wall
 CSE                   :  53.15 (20%) usr   0.59 ( 2%) sys  60.06 (18%) wall
 CSE 2                 :  36.92 (14%) usr   0.18 ( 1%) sys  41.34 (12%) wall
 tree SSA other        :   6.88 ( 3%) usr   5.10 (21%) sys  13.43 ( 4%) wall
 tree PRE              :   5.38 ( 2%) usr   0.41 ( 2%) sys   6.24 ( 2%) wall
 PRE                   :   5.43 ( 2%) usr   0.58 ( 2%) sys   6.47 ( 2%) wall

CSE is just slow.
Comment 6 Martin Sebor 2017-01-11 22:37:21 UTC 
Gcj has been removed from GCC in the 7.0 cycle.  Closing as Won't Fix.