Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
> error messages compiling the switch core if I turn on optimizations.
I've checked in a hook in ops2c.pl that splits the switched core all 300
ops. If that works, we can provide some confi
At 12:27 PM -0500 11/23/04, Dan Sugalski wrote:
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's som
At 9:17 AM -0800 11/23/04, Bill Coffman wrote:
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch?
It was the patch originally attached to this ticket, over a stock
parrot from CVS. If there's something else to try let me know -- I'm
all for i
Wait, I just thought of a huge change.
Dan, Does the patch you have implement Leo's U_NON_VOLATILE patch? If
so, that restricts from 32 to 16 registers, in various cases for
*non-volatile* symbols (did I get that right?). Anyway, the symbols
that cross sub calls can only use 16 registers, where
At 5:40 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit unt
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can't. My dev machine's running gcc 2.95.4, and gcc throws lisp
> error messages compiling the switch core if I turn on optimizations.
You could try:
- perl Configure.pl --optimize
- make -s
- wait a bit until first files start compiling
- interrupt it
At 8:25 AM -0800 11/23/04, Bill Coffman wrote:
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the run
at 19.5 minutes.
I'd be interested in
On Tue, 23 Nov 2004 09:27:12 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> The parrot I have, which is a day or two out of date, takes 7m to
> churn through one of my pir files. With this patch, I killed the run
> at 19.5 minutes.
I'd be interested in getting this code for testing. The big one
At 4:02 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
One more note: be sure to compile Parrot optimized - the new
reg_alloc.c h
At 3:54 PM +0100 11/23/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to
churn through one of my pir files. With this patch, I killed the
run at 19.5 minutes.
Sh... That's one of the smaller ones I presume.
Nope, one of the biggest. S
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
One more note: be sure to compile Parrot optimized - the new reg_alloc.c
has some very expensive sanity checks in debug mode
Dan Sugalski wrote:
The parrot I have, which is a day or two out of date, takes 7m to churn
through one of my pir files. With this patch, I killed the run at 19.5
minutes.
Sh... That's one of the smaller ones I presume. How many basic blocks
and variables are listed with -v?
Thanks,
leo
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Okay, got some time this morning. Two of the patch hunks were already
in, so I skipped 'em. The result
At 11:35 AM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a
real number.
How does it look like? Any results already?
Nope, haven't had time, unfortunately. Work's been busy. Today, if I get
lucky.
--
Dan Sugalski wrote:
Okay. I'll apply it and take a shot. May take a few hours to get a real
number.
How does it look like? Any results already?
Thanks,
leo
At 5:32 PM +0100 11/15/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
>>Anyway: are there already numbers from the big evil subs?
I'd love to see 'em. (Or if you're asking if I've applied this and
tried it, the answer's no.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
>>The old allocator took three colors.
> Sweet.
To be precise, it used 3 colors with the pre-allocation hack turned on
that colored temps. W/o that it also used 2 colors.
>>Anyway: are there already numb
At 4:08 PM +0100 11/15/04, Leopold Toetsch wrote:
[ x4.patch ]
The register allocator seems to do a great jub. It does e.g. color a
diamond-like interference graph correctly with two colors only:
x
/ \
w z
\ /
y
(the lines denote an i
[ x4.patch ]
The register allocator seems to do a great jub. It does e.g. color a
diamond-like interference graph correctly with two colors only:
x
/ \
w z
\ /
y
(the lines denote an interference - BTW you might create some PIR could
# New Ticket Created by Bill Coffman
# Please include the string: [perl #32418]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32418 >
Failed Test Stat Wstat Total Fail Failed List of Failed
---
20 matches
Mail list logo
