| 13 |
Description: |
Description: |
| 14 |
---------------------------------------------------------------------- |
---------------------------------------------------------------------- |
| 15 |
Name: Allen Leung |
Name: Allen Leung |
| 16 |
|
Date: 2000/04/06 01:30:00 EST |
| 17 |
|
Tag: leunga-20000406-peephole-x86-SSA-2 |
| 18 |
|
Description: |
| 19 |
|
|
| 20 |
|
Forgot a few files. |
| 21 |
|
|
| 22 |
|
---------------------------------------------------------------------- |
| 23 |
|
Name: Allen Leung |
| 24 |
|
Date: 2000/04/06 00:36:00 EST |
| 25 |
|
Tag: leunga-20000406-peephole-x86-SSA |
| 26 |
|
Description: |
| 27 |
|
|
| 28 |
|
1. New Peephole code |
| 29 |
|
|
| 30 |
|
2. Minor improvement to X86 instruction selection |
| 31 |
|
|
| 32 |
|
3. Various fixes to SSA and machine description -> code translator |
| 33 |
|
|
| 34 |
|
---------------------------------------------------------------------- |
| 35 |
|
Name: Matthias Blume |
| 36 |
|
Date: 2000/04/05 12:30:00 JST |
| 37 |
|
Tag: blume_main_v110p26p2_3 |
| 38 |
|
Description: |
| 39 |
|
|
| 40 |
|
This update just merges three minor cosmetic updates to CM's sources |
| 41 |
|
to get ready for the 110.27 code freeze on Friday. No functionality |
| 42 |
|
has changed. |
| 43 |
|
|
| 44 |
|
---------------------------------------------------------------------- |
| 45 |
|
Name: Allen Leung |
| 46 |
|
Date: 2000/04/04 19:39:00 EST |
| 47 |
|
Tag: leunga-20000404-x86-asm |
| 48 |
|
Description: |
| 49 |
|
|
| 50 |
|
1. Fixed a problem in X86 assembly. |
| 51 |
|
|
| 52 |
|
Things like |
| 53 |
|
|
| 54 |
|
jmp %eax |
| 55 |
|
jmp (%eax) |
| 56 |
|
|
| 57 |
|
should be output as |
| 58 |
|
|
| 59 |
|
jmp *%eax |
| 60 |
|
jmp *(%eax) |
| 61 |
|
|
| 62 |
|
2. Assembly output |
| 63 |
|
|
| 64 |
|
Added a new flag |
| 65 |
|
|
| 66 |
|
"asm-indent-copies" (default to false) |
| 67 |
|
|
| 68 |
|
When this flag is on, parallel copies will be indented an extra level. |
| 69 |
|
|
| 70 |
|
---------------------------------------------------------------------- |
| 71 |
|
Name: Allen Leung |
| 72 |
|
Date: 2000/04/04 03:18:00 EST |
| 73 |
|
Tag: leunga-20000404-C--Moby |
| 74 |
|
Description: |
| 75 |
|
|
| 76 |
|
All of these fixes are related to C--, Moby, and my own optimization |
| 77 |
|
stuff; so they shouldn't affect SML/NJ. |
| 78 |
|
|
| 79 |
|
1. X86 |
| 80 |
|
|
| 81 |
|
Various fixes related floating point, and extensions. |
| 82 |
|
|
| 83 |
|
2. Alpha |
| 84 |
|
|
| 85 |
|
Some extra patterns related to loads with signed/zero extension |
| 86 |
|
provided by Fermin. |
| 87 |
|
|
| 88 |
|
3. Assembly |
| 89 |
|
|
| 90 |
|
When generating assemby, resolve the value of client defined constants, |
| 91 |
|
instead of generating symbolic values. This is controlled by the |
| 92 |
|
new flag "asm-resolve-constants", which is default to true. |
| 93 |
|
|
| 94 |
|
4. Machine Descriptions |
| 95 |
|
|
| 96 |
|
a. The precedence parser was slightly broken when parsing infixr symbols. |
| 97 |
|
b. The type generalizing code had the bound variables reversed, resulting |
| 98 |
|
in a problem during arity raising. |
| 99 |
|
c. Various fixes in machine descriptions. |
| 100 |
|
|
| 101 |
|
---------------------------------------------------------------------- |
| 102 |
|
Name: Matthias Blume |
| 103 |
|
Date: 2000/04/03 16:05:00 JST |
| 104 |
|
Tag: blume_main_v110p26p2_2 |
| 105 |
|
Description: |
| 106 |
|
|
| 107 |
|
I eliminated coreEnv from compInfo. Access to the "Core" structure is |
| 108 |
|
now done via the ordinary static environment that is context to each |
| 109 |
|
compilation unit. |
| 110 |
|
|
| 111 |
|
To this end, I arranged that instead of "structure Core" as "structure |
| 112 |
|
_Core" is bound in the pervasive environment. Core access is done via |
| 113 |
|
_Core (which can never be accidentially rebound because _Core is not a |
| 114 |
|
legal surface-syntax symbol). |
| 115 |
|
|
| 116 |
|
The current solution is much cleaner because the core environment is |
| 117 |
|
now simply part of the pervasive environment which is part of every |
| 118 |
|
compilation unit's context anyway. In particular, this eliminates all |
| 119 |
|
special-case handling that was necessary until now in order to deal |
| 120 |
|
with dynamic and symbolic parts of the core environment. |
| 121 |
|
|
| 122 |
|
Remaining hackery (to bind the "magic" symbol _Core) is localized in the |
| 123 |
|
compilation mananger's bootstrap compiler (actually: in the "init group" |
| 124 |
|
handling). See the comments in src/system/smlnj/init/init.cmi for |
| 125 |
|
more details. |
| 126 |
|
|
| 127 |
|
I also tried to track down all mentions of "Core" (as string argument |
| 128 |
|
to Symbol.strSymbol) in the compiler and replaced them with a |
| 129 |
|
reference to the new CoreSym.coreSym. Seems cleaner since the actual |
| 130 |
|
name appears in one place only. |
| 131 |
|
|
| 132 |
|
Binfile and bootfile format have not changed, but the switchover from |
| 133 |
|
the old "init.cmi" to the new one is a bit tricky, so I supplied new |
| 134 |
|
bootfiles anyway. |
| 135 |
|
|
| 136 |
|
---------------------------------------------------------------------- |
| 137 |
|
Name: Allen Leung |
| 138 |
|
Date: 2000/04/02 21:17:00 EST |
| 139 |
|
Tag: leunga-20000402-mltree |
| 140 |
|
Description: |
| 141 |
|
|
| 142 |
|
1. Renamed the constructor CALL in MLTREE by popular demand. |
| 143 |
|
2. Added a bunch of files from my repository. These are currently |
| 144 |
|
used by other non-SMLNJ backends. |
| 145 |
|
|
| 146 |
|
---------------------------------------------------------------------- |
| 147 |
|
Name: Allen Leung |
| 148 |
|
Date: 2000/03/31 21:15:00 EST |
| 149 |
|
Tag: leunga-20000331-aliasing |
| 150 |
|
Description: |
| 151 |
|
|
| 152 |
|
This update contains a rewritten (and hopefully more correct) module |
| 153 |
|
for extracting aliasing information from CPS. |
| 154 |
|
|
| 155 |
|
To turn on this feature: |
| 156 |
|
|
| 157 |
|
Compiler.Control.CG.memDisambiguate := true |
| 158 |
|
|
| 159 |
|
To pretty print the region information with assembly |
| 160 |
|
|
| 161 |
|
Compiler.Control.MLRISC.getFlag "asm-show-region" := true; |
| 162 |
|
|
| 163 |
|
To control how many levels of aliasing information are printed, use: |
| 164 |
|
|
| 165 |
|
Compiler.Control.MLRISC.getInt "points-to-show-level" := n |
| 166 |
|
|
| 167 |
|
The default of n is 3. |
| 168 |
|
|
| 169 |
|
---------------------------------------------------------------------- |
| 170 |
|
Name: David MacQueen |
| 171 |
|
Date: 2000/03/31 11:15:00 EST |
| 172 |
|
Tag: dbm-20000331-runtime_fix |
| 173 |
|
Description: |
| 174 |
|
|
| 175 |
|
This update contains: |
| 176 |
|
|
| 177 |
|
1. runtime/c-lib/c-libraries.c |
| 178 |
|
includes added in revision 1.2 caused compilation errors on hppa-hpux |
| 179 |
|
|
| 180 |
|
2. fix for bug 1556 |
| 181 |
|
system/Basis/Implementation/NJ/internal-signals.sml |
| 182 |
|
|
| 183 |
|
---------------------------------------------------------------------- |
| 184 |
|
Name: Matthias Blume |
| 185 |
|
Date: 2000/03/31 18:00:00 JST |
| 186 |
|
Tag: blume_main_v110p26p2_1 |
| 187 |
|
Description: |
| 188 |
|
|
| 189 |
|
This update contains: |
| 190 |
|
|
| 191 |
|
1. A small change to CM's handling of stable libraries: |
| 192 |
|
CM now maintains one "global" modmap that is used for all stable |
| 193 |
|
libraries. The use of such a global modmap maximizes sharing and |
| 194 |
|
minimizes the need for re-traversing parts of environments during |
| 195 |
|
modmap construction. (However, this has minor impact since modmap |
| 196 |
|
construction seems to account for just one percent or less of total |
| 197 |
|
compile time.) |
| 198 |
|
|
| 199 |
|
2. I added a "genmap" phase to the statistics. This is where I got the |
| 200 |
|
"one percent" number (see above). |
| 201 |
|
|
| 202 |
|
3. CM's new tool parameter mechanism just became _even_ better. :) |
| 203 |
|
- The parser understands named parameters and recursive options. |
| 204 |
|
- The "make" and "shell" tools use these new features. |
| 205 |
|
(This makes it a lot easier to cascade these tools.) |
| 206 |
|
- There is a small syntax change: named parameters use a |
| 207 |
|
|
| 208 |
|
<name> : ( <option> ... ) or |
| 209 |
|
<name> : <string> |
| 210 |
|
|
| 211 |
|
syntax. Previously, named parameters were implemented in an |
| 212 |
|
ad-hoc fashion by each tool individually (by parsing strings) |
| 213 |
|
and had the form |
| 214 |
|
|
| 215 |
|
<name>=<string> |
| 216 |
|
|
| 217 |
|
See the CM manual for a full description of these issues. |
| 218 |
|
|
| 219 |
|
---------------------------------------------------------------------- |
| 220 |
|
Name: Matthias Blume |
| 221 |
|
Date: 2000/03/30 18:00:00 JST |
| 222 |
|
Tag: blume_main_v110p26p2_0 |
| 223 |
|
Description: |
| 224 |
|
|
| 225 |
|
!!!!! WARNING !!!!!! |
| 226 |
|
!! New binfiles !! |
| 227 |
|
!!!!!!!!!!!!!!!!!!!! |
| 228 |
|
|
| 229 |
|
This update contains: |
| 230 |
|
|
| 231 |
|
1. Moderate changes to CM: |
| 232 |
|
|
| 233 |
|
- Changes to CM's tools mechanism. In particular, it is now possible |
| 234 |
|
to have tools that accept additional "command line" parameters |
| 235 |
|
(specified in the .cm file at each instance where the tool's class is |
| 236 |
|
used). |
| 237 |
|
|
| 238 |
|
This was done to accomodate the new "make" and "shell" tools which |
| 239 |
|
facilitate fairly seemless hookup to portions of code managed using |
| 240 |
|
Makefiles or Shell scripts. |
| 241 |
|
|
| 242 |
|
There are no classes "shared" or "private" anymore. Instead, the |
| 243 |
|
sharing annotation is now a parameter to the "sml" class. |
| 244 |
|
|
| 245 |
|
There is a bit of generic machinery for implementing one's own |
| 246 |
|
tools that accept command-line parameters. However, I am not yet fully |
| 247 |
|
satisfied with that part, so expect changes here in the future. |
| 248 |
|
|
| 249 |
|
All existing tools are described in the CM manual. |
| 250 |
|
|
| 251 |
|
- Slightly better error handling. (CM now surpresses many followup |
| 252 |
|
error messages that tended to be more annoying than helpful.) |
| 253 |
|
|
| 254 |
|
2. Major changes to the compiler's static environment data structures. |
| 255 |
|
|
| 256 |
|
- no CMStaticEnv anymore. |
| 257 |
|
- no CMEnv, no "BareEnvironment" (actually, _only_ BareEnvironment, |
| 258 |
|
but it is called Environment), no conversions between different |
| 259 |
|
kinds of static environments |
| 260 |
|
|
| 261 |
|
- There is still a notion of a "modmap", but such modmaps are generated |
| 262 |
|
on demand at the time when they are needed. This sounds slow, but I |
| 263 |
|
sped up the code that generates modmaps enough for this not to lead to |
| 264 |
|
a slowdown of the compiler (at least I didn't detect any). |
| 265 |
|
|
| 266 |
|
- To facilitate rapid modmap generation, static environments now |
| 267 |
|
contain an (optional) "modtree" structure. Modtree annotations are |
| 268 |
|
constructed by the unpickler during unpickling. (This means that |
| 269 |
|
the elaborator does not have to worry about modtrees at all.) |
| 270 |
|
Modtrees have the advantage that they are compositional in the same |
| 271 |
|
way as the environment data structure itself is compositional. |
| 272 |
|
As a result, modtrees never hang on to parts of an environment that |
| 273 |
|
has already been rendered "stale" by filtering or rebinding. |
| 274 |
|
|
| 275 |
|
- I went through many, many trials and errors before arriving at the |
| 276 |
|
current solution. (The initial idea of "linkpaths" did not work.) |
| 277 |
|
But the result of all this is that I have touched a lot of files that |
| 278 |
|
depend on the "modules" and "types" data structures (most of the |
| 279 |
|
elaborator). There were a lot of changes during my "linkpath" trials |
| 280 |
|
that could have been reverted to their original state but weren't. |
| 281 |
|
Please, don't be too harsh on me for messing with this code a bit more |
| 282 |
|
than what was strictly necessary... (I _did_ resist the tempation |
| 283 |
|
of doing any "global reformatting" to avoid an untimely death at |
| 284 |
|
Dave's hands. :) |
| 285 |
|
|
| 286 |
|
- One positive aspect of the previous point: At least I made sure that |
| 287 |
|
all files that I touched now compile without warnings (other than |
| 288 |
|
"polyEqual"). |
| 289 |
|
|
| 290 |
|
- compiler now tends to run "leaner" (i.e., ties up less memory in |
| 291 |
|
redundant modmaps) |
| 292 |
|
|
| 293 |
|
---------------------------------------------------------------------- |
| 294 |
|
Name: Allen Leung |
| 295 |
|
Date: 2000/03/29 18:00:00 |
| 296 |
|
Tag: leunga-20000327-mlriscGen_hppa_alpha_x86 |
| 297 |
|
Boot files (optional): ftp://react-ilp.cs.nyu.edu/leunga/110.26.1-sml.boot.x86-unix-20000330.tar.gz |
| 298 |
|
Description: |
| 299 |
|
|
| 300 |
|
This update contains *MAJOR* changes to the way code is generated from CPS |
| 301 |
|
in the module mlriscGen, and in various backend modules. |
| 302 |
|
|
| 303 |
|
CHANGES |
| 304 |
|
======= |
| 305 |
|
|
| 306 |
|
1. MLRiscGen: forward propagation fix. |
| 307 |
|
|
| 308 |
|
There was a bug in forward propagation introduced at about the same time |
| 309 |
|
as the MLRISC x86 backend, which prohibits coalescing to be |
| 310 |
|
performed effectively in loops. |
| 311 |
|
|
| 312 |
|
Effect: speed up of loops in RISC architectures. |
| 313 |
|
By itself, this actually slowed down certain benchmarks on the x86. |
| 314 |
|
|
| 315 |
|
2. MLRiscGen: forward propagating addresses from consing. |
| 316 |
|
|
| 317 |
|
I've changed the way consing code is generated. Basically I separated |
| 318 |
|
out the initialization part: |
| 319 |
|
|
| 320 |
|
store tag, offset(allocptr) |
| 321 |
|
store elem1, offset+4(allocptr) |
| 322 |
|
store elem2, offset+8(allocptr) |
| 323 |
|
... |
| 324 |
|
store elemn, offset+4n(allocptr) |
| 325 |
|
|
| 326 |
|
and the address computation part: |
| 327 |
|
|
| 328 |
|
celladdr <- offset+4+alloctpr |
| 329 |
|
|
| 330 |
|
and move the address computation part |
| 331 |
|
|
| 332 |
|
Effect: register pressure is generally lower as a result. This |
| 333 |
|
makes compilation of certain expressions much faster, such as |
| 334 |
|
long lists with non-trivial elements. |
| 335 |
|
|
| 336 |
|
[(0,0), (0,0), .... (0,0)] |
| 337 |
|
|
| 338 |
|
3. MLRiscGen: base pointer elimination. |
| 339 |
|
|
| 340 |
|
As part of the linkage mechanism, we generate the sequence: |
| 341 |
|
|
| 342 |
|
L: ... <- start of the code fragment |
| 343 |
|
|
| 344 |
|
L1: |
| 345 |
|
base pointer <- linkreg - L1 + L |
| 346 |
|
|
| 347 |
|
The base pointer was then used for computing relocatable addresses |
| 348 |
|
in the code fragment. Frequently (such as in lots of continuations) |
| 349 |
|
this is not needed. We now eliminate this sequence whenever possible. |
| 350 |
|
|
| 351 |
|
For compile time efficiency, I'm using a very stupid local heuristic. |
| 352 |
|
But in general, this should be done as a control flow analysis. |
| 353 |
|
|
| 354 |
|
Effect: Smaller code size. Speed up of most programs. |
| 355 |
|
|
| 356 |
|
4. Hppa back end |
| 357 |
|
|
| 358 |
|
Long jumps in span dependence resolution used to depend on the existence |
| 359 |
|
of the base pointer. |
| 360 |
|
|
| 361 |
|
A jump to a long label L was expanded into the following sequence: |
| 362 |
|
|
| 363 |
|
LDIL %hi(L-8192), %r29 |
| 364 |
|
LDO %lo(L-8192)(%r29), %r29 |
| 365 |
|
ADD %r29, baseptr, %r29 |
| 366 |
|
BV,n %r0(%r29) |
| 367 |
|
|
| 368 |
|
In the presence of change (3) above, this will not work. I've changed |
| 369 |
|
it so that the following sequence of instructions are generated, which |
| 370 |
|
doesn't mention the base pointer at all: |
| 371 |
|
|
| 372 |
|
BL,n L', %r29 /* branch and link, L' + 4 -> %r29 */ |
| 373 |
|
L': ADDIL L-(L'+4), %r29 /* Compute address of L */ |
| 374 |
|
BV,n %r0(%r29) /* Jump */ |
| 375 |
|
|
| 376 |
|
5. Alpha back end |
| 377 |
|
|
| 378 |
|
New alpha instructions LDB/LDW have been added, as per Fermin's |
| 379 |
|
suggestions. This is unrelated to all other changes. |
| 380 |
|
|
| 381 |
|
6. X86 back end |
| 382 |
|
|
| 383 |
|
I've changed andl to testl in the floating point test sequence |
| 384 |
|
whenever appropriate. The Intel optimization guide states that |
| 385 |
|
testl is perferable to andl. |
| 386 |
|
|
| 387 |
|
7. RA (x86 only) |
| 388 |
|
|
| 389 |
|
I've improved the spill propagation algorithm, using an approximation |
| 390 |
|
of maximal weighted independent sets. This seems to be necessary to |
| 391 |
|
alleviate the negative effect in light of the slow down in (1). |
| 392 |
|
|
| 393 |
|
I'll write down the algorithm one of these days. |
| 394 |
|
|
| 395 |
|
8. MLRiscGen: frequencies |
| 396 |
|
|
| 397 |
|
I've added an annotation that states that all call gc blocks have zero |
| 398 |
|
execution frequencies. This improves register allocation on the x86. |
| 399 |
|
|
| 400 |
|
BENCHMARKS |
| 401 |
|
========== |
| 402 |
|
|
| 403 |
|
I've only perform the comparison on 110.25. |
| 404 |
|
|
| 405 |
|
The platforms are: |
| 406 |
|
|
| 407 |
|
HPPA A four processor HP machine (E9000) with 5G of memory. |
| 408 |
|
X86 A 300Hhz Pentium II with 128M of memory, and |
| 409 |
|
SPARC An Ultra sparc 2 with 512M of memory. |
| 410 |
|
|
| 411 |
|
I used the following parameters for the SML benchmarks: |
| 412 |
|
|
| 413 |
|
@SMLalloc |
| 414 |
|
HPPA 256k |
| 415 |
|
SPARC 512k |
| 416 |
|
X86 256k |
| 417 |
|
|
| 418 |
|
COMPILATION TIME |
| 419 |
|
---------------- |
| 420 |
|
Here are the numbers comparing the compilation times of the compilers. |
| 421 |
|
I've only compared 110.25 compiling the new sources versus |
| 422 |
|
a fixpoint version of the new compiler compiling the same. |
| 423 |
|
|
| 424 |
|
110.25 New |
| 425 |
|
Total Time in RA Spill+Reload Total Time In RA Spill+Reload |
| 426 |
|
HPPA 627s 116s 2684+3584 599s 95s 1003+1879 |
| 427 |
|
SPARC 892s 173s 2891+3870 708s 116s 1004+1880 |
| 428 |
|
X86 999s 315s 94006+130691 987s 296s 108877+141957 |
| 429 |
|
|
| 430 |
|
110.25 New |
| 431 |
|
Code Size Code Size |
| 432 |
|
HPPA 8596736 8561421 |
| 433 |
|
SPARC 8974299 8785143 |
| 434 |
|
X86 9029180 8716783 |
| 435 |
|
|
| 436 |
|
So in summary, things are at least as good as before. Dramatic |
| 437 |
|
reduction in compilation is obtained on the Sparc; I can't explain it, |
| 438 |
|
but it is reproducible. Perhaps someone should try to reproduce this |
| 439 |
|
on their own machines. |
| 440 |
|
|
| 441 |
|
SML BENCHMARKS |
| 442 |
|
-------------- |
| 443 |
|
|
| 444 |
|
On the average, all benchmarks perform at least as well as before. |
| 445 |
|
|
| 446 |
|
HPPA Compilation Time Spill+Reload Run Time |
| 447 |
|
110.25 New 110.25 New 110.25 New |
| 448 |
|
|
| 449 |
|
barnesHut 3.158 3.015 4.75% 1+1 0+0 2.980 2.922 2.00% |
| 450 |
|
boyer 6.152 5.708 7.77% 0+0 0+0 0.218 0.213 2.34% |
| 451 |
|
count-graphs 1.168 1.120 4.32% 0+0 0+0 22.705 23.073 -1.60% |
| 452 |
|
fft 0.877 0.792 10.74% 1+3 1+3 0.602 0.587 2.56% |
| 453 |
|
knuthBendix 3.180 2.857 11.32% 0+0 0+0 0.675 0.662 2.02% |
| 454 |
|
lexgen 6.190 5.290 17.01% 0+0 0+0 0.913 0.788 15.86% |
| 455 |
|
life 0.803 0.703 14.22% 25+25 0+0 0.153 0.140 9.52% |
| 456 |
|
logic 2.048 2.007 2.08% 6+6 1+1 4.133 4.008 3.12% |
| 457 |
|
mandelbrot 0.077 0.080 -4.17% 0+0 0+0 0.765 0.712 7.49% |
| 458 |
|
mlyacc 22.932 20.937 9.53% 154+181 32+57 0.468 0.430 8.91% |
| 459 |
|
nucleic 5.183 5.060 2.44% 2+2 0+0 0.125 0.120 4.17% |
| 460 |
|
ratio-regions 3.357 3.142 6.84% 0+0 0+0 116.225 113.173 2.70% |
| 461 |
|
ray 1.283 1.290 -0.52% 0+0 0+0 2.887 2.855 1.11% |
| 462 |
|
simple 6.307 6.032 4.56% 28+30 5+7 3.705 3.658 1.28% |
| 463 |
|
tsp 0.888 0.862 3.09% 0+0 0+0 7.040 6.893 2.13% |
| 464 |
|
vliw 24.378 23.455 3.94% 106+127 25+45 2.758 2.707 1.91% |
| 465 |
|
-------------------------------------------------------------------------- |
| 466 |
|
Average 6.12% 4.09% |
| 467 |
|
|
| 468 |
|
SPARC Compilation Time Spill+Reload Run Time |
| 469 |
|
110.25 New 110.25 New 110.25 New |
| 470 |
|
|
| 471 |
|
barnesHut 3.778 3.592 5.20% 2+2 0+0 3.648 3.453 5.65% |
| 472 |
|
boyer 6.632 6.110 8.54% 0+0 0+0 0.258 0.242 6.90% |
| 473 |
|
count-graphs 1.435 1.325 8.30% 0+0 0+0 33.672 34.737 -3.07% |
| 474 |
|
fft 0.980 0.940 4.26% 3+9 2+6 0.838 0.827 1.41% |
| 475 |
|
knuthBendix 3.590 3.138 14.39% 0+0 0+0 0.962 0.967 -0.52% |
| 476 |
|
lexgen 6.593 6.072 8.59% 1+1 0+0 1.077 1.078 -0.15% |
| 477 |
|
life 0.972 0.868 11.90% 26+26 0+0 0.143 0.140 2.38% |
| 478 |
|
logic 2.525 2.387 5.80% 7+7 1+1 5.625 5.158 9.05% |
| 479 |
|
mandelbrot 0.090 0.093 -3.57% 0+0 0+0 0.855 0.728 17.39% |
| 480 |
|
mlyacc 26.732 23.827 12.19% 162+189 32+57 0.550 0.560 -1.79% |
| 481 |
|
nucleic 6.233 6.197 0.59% 3+3 0+0 0.163 0.173 -5.77% |
| 482 |
|
ratio-regions 3.780 3.507 7.79% 0+0 0+0 133.993 131.035 2.26% |
| 483 |
|
ray 1.595 1.550 2.90% 1+1 0+0 3.440 3.418 0.63% |
| 484 |
|
simple 6.972 6.487 7.48% 29+32 5+7 3.523 3.525 -0.05% |
| 485 |
|
tsp 1.115 1.063 4.86% 0+0 0+0 7.393 7.265 1.77% |
| 486 |
|
vliw 27.765 24.818 11.87% 110+135 25+45 2.265 2.135 6.09% |
| 487 |
|
---------------------------------------------------------------------------- |
| 488 |
|
Average 6.94% 2.64% |
| 489 |
|
|
| 490 |
|
X86 Compilation Time Spill+Reload Run Time |
| 491 |
|
110.25 New 110.25 New 110.25 New |
| 492 |
|
|
| 493 |
|
barnesHut 5.530 5.420 2.03% 593+893 597+915 3.532 3.440 2.66% |
| 494 |
|
boyer 8.768 7.747 13.19% 493+199 301+289 0.327 0.297 10.11% |
| 495 |
|
count-graphs 2.040 2.010 1.49% 298+394 315+457 26.578 28.660 -7.26% |
| 496 |
|
fft 1.327 1.302 1.92% 112+209 115+210 1.055 0.962 9.71% |
| 497 |
|
knuthBendix 5.218 5.475 -4.69% 451+598 510+650 0.928 0.932 -0.36% |
| 498 |
|
lexgen 9.970 9.623 3.60% 1014+841 1157+885 0.947 0.928 1.97% |
| 499 |
|
life 1.183 1.183 0.00% 162+182 145+148 0.127 0.103 22.58% |
| 500 |
|
logic 3.285 3.512 -6.45% 514+684 591+836 5.682 5.577 1.88% |
| 501 |
|
mandelbrot 0.147 0.143 2.33% 38+41 33+54 0.703 0.690 1.93% |
| 502 |
|
mlyacc 35.457 32.763 8.22% 3496+4564 3611+4860 0.552 0.550 0.30% |
| 503 |
|
nucleic 7.100 6.888 3.07% 239+168 201+158 0.175 0.173 0.96% |
| 504 |
|
ratio-regions 6.388 6.843 -6.65% 1182+257 981+300 120.142 120.345 -0.17% |
| 505 |
|
ray 2.332 2.338 -0.29% 346+398 402+494 3.593 3.540 1.51% |
| 506 |
|
simple 9.912 9.903 0.08% 1475+941 1579+1168 3.057 3.178 -3.83% |
| 507 |
|
tsp 1.623 1.532 5.98% 266+200 250+211 8.045 7.878 2.12% |
| 508 |
|
vliw 33.947 35.470 -4.29% 2629+2774 2877+3171 2.072 1.890 9.61% |
| 509 |
|
---------------------------------------------------------------------------- |
| 510 |
|
Average 1.22% 3.36% |
| 511 |
|
|
| 512 |
|
---------------------------------------------------------------------- |
| 513 |
|
Name: Allen Leung |
| 514 |
Date: 2000/03/23 16:25:00 |
Date: 2000/03/23 16:25:00 |
| 515 |
Tag: leunga-20000323-fix_x86_alpha |
Tag: leunga-20000323-fix_x86_alpha |
| 516 |
Description: |
Description: |
Parent Directory
| 
Revision Log
| 
Patch
