Re: optimizer?

On 1/7/24 15:18, ToddAndMargo via perl6-users wrote: sub DirectoryExists( Str $DirPath --> Bool ) { return "$DirPath".IO.d.Bool; }  # $Full DirPath format is `H:\MyDocsBackup` Problem:  sometimes DirectoryExists lies about backup1 existing. Here is what I am up against. You will

Re: optimizer?

On 1/7/24 06:16, Parrot Raiser wrote: What's the reason behind the request? Hi Parrot, The reason is to eliminate the Optimizer as a source of weird problems. I have written a wrapper for Cobian Backup/Reflector that rotates backup sets. Cobain has is own database to keep track of backup

Re: optimizer?

On 7 Jan 2024, at 07:09, ToddAndMargo via perl6-users wrote: Hi All, Is there a switch on the command line to disable the code optimizer? Many thanks, -T On 1/7/24 04:24, Elizabeth Mattijsen wrote: > $ raku --help > > ... > --optimize=level use the given level of optimi

Re: optimizer?

..@perl.org> wrote: > > > > Hi All, > > > > Is there a switch on the command line to disable the code optimizer? > > > > Many thanks, > > -T > >

Re: optimizer?

$ raku --help ... --optimize=level use the given level of optimization (0..3) ... > On 7 Jan 2024, at 07:09, ToddAndMargo via perl6-users > wrote: > > Hi All, > > Is there a switch on the command line to disable the code optimizer? > > Many thanks, > -T

optimizer?

Hi All, Is there a switch on the command line to disable the code optimizer? Many thanks, -T

[perl #129812] [JVM][OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

This now works on the JVM backend, too. Fixed with https://github.com/rakudo/rakudo/commit/12d4514a3d I'm closing this ticket as 'resolved'.

[perl #129812] [JVM][OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

This is still a problem on the JVM backend. I tried a second time to find the underlying problem and arrived at the same conclusion: There seems to be something wrong in 'analyze_dispatch'. When running the given code multi foo ($) {"right" }; multi foo ($ is rw) {"wrong"}; say foo "42"

[perl #130761] [OPTIMIZER] An if-block confuses &?ROUTINE to point at the wrong outer routine

On Thu, 04 Apr 2019 22:59:38 -0700, barto...@gmx.de wrote: > I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm. For the record: https://github.com/perl6/roast/commit/aaf7ad02fc

[perl #130761] [OPTIMIZER] An if-block confuses &?ROUTINE to point at the wrong outer routine

Just for the record: This seems to work on the JVM backend: $ ./perl6-j --optimize=3 -e 'sub f() { sub g() { if True { return &?ROUTINE.name } } }; say f()()' g I'm going to unfudge the test in S02-magicals/sub.t for rakudo.jvm.

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote: > Seems an optimizer bug. Running with --optimize=off does not have the > issue present. Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #129912] [OPTIMIZER] Subset produces Cannot invoke this object (REPR: Null; VMNull)

On Wed, 14 Dec 2016 15:14:27 -0800, c...@zoffix.com wrote: > Seems an optimizer bug. Running with --optimize=off does not have the > issue present. Fixed and tested as https://github.com/rakudo/rakudo/issues/1465

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote: > On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net > wrote: > > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote: > > > I dug at this bug a few months back, but lost my notes on my > > > findings. > >

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

On Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hen...@bredband.net wrote: > On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net > wrote: > > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote: > > > I dug at this bug a few months back, but lost my notes on my > > > findings. > >

[perl #129790] [OPTIMIZER] Giving a sub to a map fails

On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote: > Maybe it is worth noting that this is pretty much a regression (even > though an > old one, and caused by a non-optimizer change). > > (2016-08-09) > https://github.com/ra

[perl #129790] [OPTIMIZER] Giving a sub to a map fails

On Sat, 14 Oct 2017 18:38:47 -0700, alex.jakime...@gmail.com wrote: > Maybe it is worth noting that this is pretty much a regression (even > though an > old one, and caused by a non-optimizer change). > > (2016-08-09) > https://github.com/ra

[perl #130613] [OPTIMIZER][LTA] "if" without "else" much slower than "if" with empty "else"

On Sat, 21 Jan 2017 11:45:10 -0800, ale...@yahoo.com wrote: > Take a look at the following examples - the second is more than > 10x(!!!) faster: > m: my int $i = 0; loop { if $i++ == 10_000_000 { last }}; say now - > INIT now;rakudo-moar f97d5c: OUTPUT«2.0606382␤» > m: my int $i = 0; loop { if

[perl #130613] [OPTIMIZER][LTA] "if" without "else" much slower than "if" with empty "else"

On Sat, 21 Jan 2017 11:45:10 -0800, ale...@yahoo.com wrote: > Take a look at the following examples - the second is more than > 10x(!!!) faster: > m: my int $i = 0; loop { if $i++ == 10_000_000 { last }}; say now - > INIT now;rakudo-moar f97d5c: OUTPUT«2.0606382␤» > m: my int $i = 0; loop { if

[perl #129812] [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

ix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi > > > foo ($ is rw) {"wrong"}; say foo "42"' > > > wrong > > > > > > And if we turn off the optimizer, we get the right candidate called > > > (same would h

[perl #129790] [OPTIMIZER] Giving a sub to a map fails

Maybe it is worth noting that this is pretty much a regression (even though an old one, and caused by a non-optimizer change). (2016-08-09) https://github.com/rakudo/rakudo/commit/328402599c16077e182bb38baf68e435b8bc1082 Output before and after: https://gist.github.com

[perl #129812] [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

$ is rw) {"wrong"}; say foo "42"' > > wrong > > > > And if we turn off the optimizer, we get the right candidate called > > (same would happen if we add more complex sub bodies, so possibly the > > sub gets inlined): > > > > zoffix@lelian

[perl #130855] [SPESH][OPTIMIZER] glitch with anon vars causes incorrect `Cannot assign to an immutable value` error

On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote: > Expected no errors, but in the first case it complains about > assignment to immutable value even though none exist in the code. > > zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 { > $ = foo }; say now - INIT now'

[perl #130855] [SPESH][OPTIMIZER] glitch with anon vars causes incorrect `Cannot assign to an immutable value` error

On Fri, 24 Feb 2017 15:02:23 -0800, c...@zoffix.com wrote: > Expected no errors, but in the first case it complains about > assignment to immutable value even though none exist in the code. > > zoffix@VirtualBox:~$ perl6 -e 'm: sub foo () {$ = 42}; for ^200 { > $ = foo }; say now - INIT now'

[perl #129812] [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

On Wed, 05 Oct 2016 14:23:57 -0700, c...@zoffix.com wrote: > > This code shows the bug: > > zoffix@leliana:~$ perl6 -e 'm: multi foo ($) {"right" }; multi > foo ($ is rw) {"wrong"}; say foo "42"' > wrong > > And if we tur

[perl #130404] [OPTIMIZER] || with native int returns "1" instead of the int's value

Tests in https://github.com/perl6/roast/commit/b1f116fdd5181274cda1a520194488da82c10a7e

[perl #130404] [OPTIMIZER] || with native int returns "1" instead of the int's value

Tests in https://github.com/perl6/roast/commit/b1f116fdd5181274cda1a520194488da82c10a7e

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hen...@bredband.net wrote: > On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote: > > I dug at this bug a few months back, but lost my notes on my > > findings. > > > > As I recall it, the 128655 happens in BOOTSTRAP.nqp in > >

[perl #128655] [OPTIMIZER] Mixup in candidates through optimizer

On Tue, 31 Jan 2017 09:05:52 -0800, c...@zoffix.com wrote: > I dug at this bug a few months back, but lost my notes on my findings. > > As I recall it, the 128655 happens in BOOTSTRAP.nqp in > find_best_dispatchee() the non-native candidate ends up being first in > the list and that's why it's

[perl #130404] [OPTIMIZER] || with native int returns "1" instead of the int's value

11-182-gea28845 built on MoarVM version > 2016.11-41-gd2139b5 > implementing Perl 6.c. > zoffix@VirtualBox:~$ > > > There's a pretty good chance that the optimizer evaluates the > statement and encounters NQP bug involving ||: > https://github.com/perl6/nqp/issues/332 Looks as

[perl #130855] [SPESH][OPTIMIZER] glitch with anon vars causes incorrect `Cannot assign to an immutable value` error

# New Ticket Created by Zoffix Znet # Please include the string: [perl #130855] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=130855 > Expected no errors, but in the first case it complains about assignment to immutable

[perl #130404] [OPTIMIZER] || with native int returns "1" instead of the int's value

ion 2016.11-182-gea28845 built on MoarVM version 2016.11-41-gd2139b5 implementing Perl 6.c. zoffix@VirtualBox:~$ There's a pretty good chance that the optimizer evaluates the statement and encounters NQP bug involving ||: https://github.com/perl6/nqp/issues/332

[perl #129812] [OPTIMIZER] `is rw` candidates get called even if a non-rw argument is passed

ot;right" }; multi foo ($ is rw) {"wrong"}; say foo "42"' wrong And if we turn off the optimizer, we get the right candidate called (same would happen if we add more complex sub bodies, so possibly the sub gets inlined): zoffix@leliana:~$ perl6 --optimize=o

[perl #128655] Mixup in candidates through optimizer

Posting on behalf of dogbert17: I believe that I have encountered the same bug under different circumstances. With the help of hackedNODE and others on #perl6 it seems as if the problem described below also suffers from the wrong multi candidate being called. In

[perl #129790] [OPTIMIZER] Giving a sub to a map fails

Playing around I found that the following change made your examples work as expected: diff --git a/src/Perl6/Optimizer.nqp b/src/Perl6/Optimizer.nqp index 12398ba..9102b7f 100644 --- a/src/Perl6/Optimizer.nqp +++ b/src/Perl6/Optimizer.nqp @@ -1082,7 +1082,8 @@ class Perl6::Optimizer

[perl #129790] [OPTIMIZER] Giving a sub to a map fails

PRC/rakudo$ ./perl6 -e 'sub foo ($) {say "meow"}; ^4 .map: ' ===SORRY!=== Cannot find method 'count' on object of type NQPMu However, everything works fine, if we turn off the optimizer: zoffix@VirtualBox:~/CPANPRC/rakudo$ ./perl6 --optimize=off -e '^4 .map: {};' Canno

[perl #128693] Regex optimizer on \s+$ is "dumb as bricks"

nice test case, though! [14:11] I'll submit this. At least it will be useful as a note for the future. [14:11] our regex optimizer is dumb as bricks ;) -- Aaron Sherman, M.: P: 617-440-4332 Google Talk, Email and Google Plus: a...@ajs.com Toolsmith, developer, gamer and life-long student.

Re: [perl #128655] Mixup in candidates through optimizer

Please reply to all on tickets, so that comments also end up back in RT as well. (I linked the tickets based on your comment here.) On Mon, Jul 18, 2016 at 4:10 AM, mt1957 wrote: > Hi Elizabeth, > > Need to mention that there was a ticket #128624 created 'Buf initialization >

Re: [perl #128655] Mixup in candidates through optimizer

Hi Elizabeth, Need to mention that there was a ticket #128624 created 'Buf initialization error'. Regards, Marcel Timmerman

[perl #128655] Mixup in candidates through optimizer

an Int, and that fails the nqp::istype($a,Int) test. It *feels* like it calling the int/int candidate, when it thinks it's calling the Int:D/Int:D candidate. Since the int/int candidate returns an int, but the optimizer probably thinks it is getting an Int, the native is not marshalled into

[perl #128092] Optimizer 2+ leaks out native

uot;a" =:= "a" || 0 # must be runtime rakudo-moar ac36d2: OUTPUT«True␤» That seems of another level to me. looks like an optimizer bug: $ perl6 --optimize=0 -e 'my $a = "a"; say $a =:= $a || 0' True $ perl6 --optimize=2 -e 'my $

[perl #126585] Optimizer too greedy when "is rw" in play

t; rakudo-moar 8b834c: ( no output ) [21:58:08] m: sub a($x is rw) { $x; }; { a 42 } # seems to be optimizer related [21:58:08] <+camelia> rakudo-moar 8b834c: ( no output ) [21:58:19] $ perl6 --optimize=off -e 'sub a($x is rw) { $x }; { a 42 }' [21:58:19] Parameter '$x

[perl #113754] [BUG] optimizer has difficulty with long expressions

On Tue Jun 19 11:51:14 2012, pmichaud wrote: Refined from a case given by harmil++ on #perl6, the optimizer seems to have problems with long expressions. pmichaud@kiwi:~/p6/rakudo$ cat z #!/bin/bash for size in 1 10 100 500 1000 1; do code=$(./perl6 -e say (1..$size).join

[perl #113754] [BUG] optimizer has difficulty with long expressions

# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #113754] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=113754 Refined from a case given by harmil++ on #perl6, the optimizer seems

Re: IMCC optimizer instruction duplication and opcode write/reads

Argh. Just realised my old address, [EMAIL PROTECTED], could receive emails but not send them (not even to itself!) On Dec 31, 2005, at 15:43, Amos Robinson wrote: -- A copy_ins() function would be nice, if needed. However, this doesn't seem to work with e.g. set_args. Why? In my local

Re: IMCC optimizer instruction duplication and opcode write/reads

into the PCC stuff you did. Copying these instructions should work after all the directives are expanded, i.e. when the optimizer sees it. Ahh, okay. How many ops would you say there are that change contents of non-LHS args? I don't want to cause too much trouble, but for used_once I think some

Re: IMCC optimizer instruction duplication and opcode write/reads

On Dec 31, 2005, at 15:43, Amos Robinson wrote: I was wondering if anybody could help: the best I've found for duplicating an instruction is INS(interp, unit, ins-op, , ins-r, ins-n_r, ins-keys, 0); A copy_ins() function would be nice, if needed. However, this doesn't seem to work with

IMCC optimizer instruction duplication and opcode write/reads

I was wondering if anybody could help: the best I've found for duplicating an instruction is INS(interp, unit, ins-op, , ins-r, ins-n_r, ins-keys, 0); However, this doesn't seem to work with e.g. set_args. Is there some easy way to duplicate an instruction, or should I just give up when I see a

Re: Optimizer Documentation

Curtis Rawls wrote: As part of my Summer of Code project, I wanted to improve the documentation of the optimizer. Please svn add the .pod to docs/dev Thanks, leo

Optimizer Documentation

As part of my Summer of Code project, I wanted to improve the documentation of the optimizer. This was especially relevant for me since I had to learn it my self by trial and error and asking questions. So here is my first draft of the optimizer documentation. I tried to include the most

Re: Optimizer Documentation

Also, this is in plain text format. What is the standard way to convert a document to POD format? By rewriting it. Only took me a few minutes: =head1 NANE optimizer.pod - About the IMCC optimizer =head1 ABSTRACT This document describes how the IMCC optimizer works. =head1 DESCRIPTION

Re: [perl #27181] Optimizer bug

Simon Glover [EMAIL PROTECTED] wrote: If -O2 is used however, it prints '-1', and the hangs. Disassembly of the optimized bytecode shows that it is being optimized to: -O2 shouldn't do anything for PASM code and it seems that it got more broken recently as it was. I'll disable it for now.

[perl #27181] Optimizer bug

# New Ticket Created by Simon Glover # Please include the string: [perl #27181] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27181 This code (a cut-down version of mops.pasm): setI2, 0 set

Re: [PATCH] gcc optimizer bug workaround in SArray

Luke Palmer [EMAIL PROTECTED] wrote: gcc 3.2 has a bug that makes SArray's shift_* not work when compiled with optimization. This works around it (and is arguably better style anyway). gcc will receive a bug report if I can manage to reduce the problem. Thanks, applied. leo

[PATCH] gcc optimizer bug workaround in SArray

gcc 3.2 has a bug that makes SArray's shift_* not work when compiled with optimization. This works around it (and is arguably better style anyway). gcc will receive a bug report if I can manage to reduce the problem. Index: classes/sarray.pmc

[perl #22359] IMCC Optimizer fails with various types of hand-rolled loops

# New Ticket Created by Clinton A. Pierce # Please include the string: [perl #22359] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=22359 The IMCC optimizer run with these options: ..\..\imcc\imcc -Op1 -d60

Re: [perl #22359] IMCC Optimizer fails with various types of hand-rolled loops

Clinton A. Pierce [EMAIL PROTECTED] wrote: ..\..\imcc\imcc -Op1 -d60 err.imc Please note: -Op does optimize PASM code, that wouldn't get optimized else. For .imc files just using -O1 suffices. Bug #1: Issues the error message (now a warning, but probably a problem nontheless):

Re: [perl #21476] [imcc] problems with the optimizer under OS X

of a repeat of the old ld: multiple definitions of symbol problem (ticket #17159). I fixed that with the attached patch. Thanks for the patch, applied. Now that it compiles, several of the optimizer tests fail. The problem seems to be unrelated to the patch because the tests pass with the patch on my

[perl #21476] [imcc] problems with the optimizer under OS X

definitions of symbol problem (ticket #17159). I fixed that with the attached patch. Now that it compiles, several of the optimizer tests fail. The problem seems to be unrelated to the patch because the tests pass with the patch on my Slackware box. Hope this is useful. Allison ... t/imcpasm

Re: Using imcc as JIT optimizer

Leopold Toetsch wrote: Phil Hassey wrote: But with a processor with 16 registers (do such things exist?). Parrot would be overflowing registers that it could have been using in the JIT. RISC processor have a lot of them. But before there are unused processor registers, we will allocate P

Re: Using imcc as JIT optimizer

Nicholas Clark [EMAIL PROTECTED] writes: On Wed, Feb 26, 2003 at 02:21:32AM +0100, Angel Faus wrote: [snip lots of good stuff] All this is obviously machine dependent: the code generated should only run in the machine it was compiled for. So we should always keep the original imc code in

[CVS ci] Using imcc as JIT optimizer #3

by parrots JIT code, to get sections and register mappings. This is significantly faster then current's jit optimizer, which has a relatively high impact on program load times. The JIT loader looks at the packfile now, and uses either method to generate information needed for actually producing bytecode

Re: Using imcc as JIT optimizer

On Tue, Feb 25, 2003 at 11:58:41PM +0100, Leopold Toetsch wrote: Nicholas Clark wrote: [thanks for the explanation] And is this all premature optimisation, give that we haven't got objects, exceptions, IO or a Z-code interpreter yet? And yes: We don't have exceptions and threads yet. The

Re: Using imcc as JIT optimizer

[snip] Maybe we starting to get to the point of having imcc deliver parrot bytecode if you want to be portable, and something approaching native machine code if you want speed. IMHO yes, the normal options produce a plain PBC file, more or less optimized at PASM level, the -Oj option is

Re: Using imcc as JIT optimizer

Phil Hassey wrote: ... The current bytecode from parrot already has potential for slowing things down, and that's what worries me here. I don't see that. My understanding is that PBC has a limit of 16 (32?) integer registers. When a code block needs more than 16 registers, they are overflowed

Re: Using imcc as JIT optimizer

[ you seem to be living some hors ahead in time ] Yep, sorry about that. The problem stays the same: spilling processors to parrot's or parrots to array. Thinking a bit more about it, now I believe that the best way to do it would be: (1) First, do a register allocation for machine

Re: Using imcc as JIT optimizer

load/store ops and an additional CFG/register usage PBC section. But running it does require less memory, because the JIT optimizer doesn't have to create all the internal bookkeeping tables. Cheers, Phil leo

Re: Using imcc as JIT optimizer

Angel Faus wrote: (1) First, do a register allocation for machine registers, assuming that there are N machine registers and infinite parrot registers. This uses equally the top N used registers for processor regs. The spilling for (1) is loading/moving them to parrot registers/temp

Re: Using imcc as JIT optimizer

Although it might be nice if IMC were binary at this stage (for some feel-good-reason?). You mean, that a HL like perl6 should produce a binary equivalent to ther current .imc file? Yep - this was discussed already, albeit there was no discussion, how this should look like. And the lexer

Re: Using imcc as JIT optimizer

Leopold Toetsch wrote: - do register allocation for JIT in imcc - use the first N registers as MAPped processor registers I have committed the next bunch of changes and an updated jit.pod. - it should now be platform independent, *but* other platforms have to define what they consider as

Re: Using imcc as JIT optimizer

I explained very badly. The issue is not spilling (at the parrot level) The problem is: if you only pick the highest priority parrot registers and put them in real registers you are losing oportunities where copying the date once will save you from copying it many times. You are, in some

Re: Using imcc as JIT optimizer

Angel Faus wrote: Saturday 22 February 2003 16:28, Leopold Toetsch wrote: With your approach there are three levels of parrot registers: - The first N registers, which in JIT will be mapped to physical registers. - The others 32 - N parrot registers, which will be in memory. - The spilled

Re: Using imcc as JIT optimizer

On Tuesday 25 February 2003 08:51, Leopold Toetsch wrote: Angel Faus wrote: Saturday 22 February 2003 16:28, Leopold Toetsch wrote: With your approach there are three levels of parrot registers: - The first N registers, which in JIT will be mapped to physical registers. - The

Re: Using imcc as JIT optimizer

Saturday 22 February 2003 16:28, Leopold Toetsch wrote: Gopal V wrote: If memory serves me right, Leopold Toetsch wrote: Ok .. well I sort of understood that the first N registers will be the ones MAPped ?. So I thought re-ordering/sorting was the operation performed. Yep. Register

Re: Using imcc as JIT optimizer

On Tue, Feb 25, 2003 at 07:18:11PM +0100, Angel Faus wrote: I believe it would be smarter if we instructed IMCC to generate code that only uses N parrot registers (where N is the number of machine register available). This way we avoid the risk of having to copy twice the data. It's not

Re: Using imcc as JIT optimizer

each code block say I need 12 registers for this block and then the JIT system would go on to do it's appropriate spilling magic with the system registers... This is somehow the approach, the current optimizer in jit.c takes. The optimizer looks at a section (a JITed part of a basic block

Re: Using imcc as JIT optimizer

, and this is -- hmmm suboptimal then :) and imcc can write out CFG information in some machine independent form, i.e. at basic block level. But no processor specific load/store instructions and such. This can help JIT optimizer to do the job faster, though it isn't that easy, because

Re: Using imcc as JIT optimizer

[ you seem to be living some hors ahead in time ] Angel Faus wrote: I explained very badly. The issue is not spilling (at the parrot level) The problem stays the same: spilling processors to parrot's or parrots to array. [ ... ] set I3, 1 add I3, I3, 1 print I3 fast_save I3, 1 set I3, 1

Re: Using imcc as JIT optimizer

Dan Sugalski wrote: At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment: - do register allocation for JIT in imcc - use the first N registers as MAPped processor

Re: Using imcc as JIT optimizer

If memory serves me right, Dan Sugalski wrote: This sounds pretty interesting, and I bet it could make things faster. The one thing to be careful of is that it's easy to get yourself into a position where you spend more time optimizing the code you're JITting than you win in the end. I

Re: Using imcc as JIT optimizer

Gopal V wrote: I'm assuming that the temporaries are the things being moved around here ?. It is not so much a matter of moving things around, but a matter of allocating (and renumbering) parrot (or for JIT) processor registers. These are of course mainly temporaries, but even when you have

Re: Using imcc as JIT optimizer

At 4:28 PM +0100 2/22/03, Leopold Toetsch wrote: Gopal V wrote: Direct hardware maps (like using CX for loop count etc) will need to be platform dependent ?. Or you could have a fixed reg that can be used for loop count (and gets mapped on hardware appropriately). We currently don't have special

Re: Using imcc as JIT optimizer

Nicholas Clark wrote in perl.perl6.internals : r-score = r-use_count + (r-lhs_use_count 2); r-score += 1 (loop_depth * 3); [...] I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc that added trap code for all classes of undefined behaviour, and caused

Re: Using imcc as JIT optimizer

Please don't take the following as a criticism of imcc - I'm sure I manage to write code with things like this all the time. On Sat, Feb 22, 2003 at 08:13:59PM +0530, Gopal V wrote: If memory serves me right, Leopold Toetsch wrote: r-score = r-use_count + (r-lhs_use_count 2);

Re: Using imcc as JIT optimizer

If memory serves me right, Leopold Toetsch wrote: I'm assuming that the temporaries are the things being moved around here ?. It is not so much a matter of moving things around, but a matter of allocating (and renumbering) parrot (or for JIT) processor registers. Ok .. well I sort of

Re: Using imcc as JIT optimizer

Gopal V wrote: If memory serves me right, Leopold Toetsch wrote: Ok .. well I sort of understood that the first N registers will be the ones MAPped ?. So I thought re-ordering/sorting was the operation performed. Yep. Register renumbering, so that the top N used (in terms of score) registers

Re: Using imcc as JIT optimizer

Nicholas Clark wrote: r-score += 1 (loop_depth * 3); until variables in 11 deep loops go undefined? Not undefined, but spilled. First *oops*, but second of course this all not final. I did change scoring several times from the code base AFAIK Angel Faus did implement. And we don't

Re: Using imcc as JIT optimizer

On Sat, Feb 22, 2003 at 08:44:12PM -, Rafael Garcia-Suarez wrote: Nicholas Clark wrote in perl.perl6.internals : r-score = r-use_count + (r-lhs_use_count 2); r-score += 1 (loop_depth * 3); [...] I wonder how hard it would be to make a --fsummon-nasal-demons flag for gcc

Re: Using imcc as JIT optimizer

On Sat, Feb 22, 2003 at 09:27:04PM +, nick wrote: On Sat, Feb 22, 2003 at 08:44:12PM -, Rafael Garcia-Suarez wrote: What undefined behaviour are you referring to exactly ? the shift overrun ? AFAIK it's very predictable (given one int size). Cases of Will you accept a shortcut

Re: Using imcc as JIT optimizer

Leopold Toetsch wrote: - do register allocation for JIT in imcc - use the first N registers as MAPped processor registers The [RFC] imcc calling conventions didn't get any response. Should I take this fact as an implict yep, fine? Here is again the relevant part, which has implications on

Re: Using imcc as JIT optimizer

At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment: - do register allocation for JIT in imcc - use the first N registers as MAPped processor registers This sounds

Re: Using imcc as JIT optimizer

Dan Sugalski wrote: At 12:09 PM +0100 2/20/03, Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment: - do register allocation for JIT in imcc - use the first N registers as MAPped processor

Re: Using imcc as JIT optimizer

Sean O'Rourke wrote: On Thu, 20 Feb 2003, Leopold Toetsch wrote: What do people think? Cool idea -- a lot of optimization-helpers could eventually be passed on to the jit (possibly in the metadata?). One thought -- the information imcc computes should be platform-independent. e.g. it

Using imcc as JIT optimizer

Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm), I did this experiment: - do register allocation for JIT in imcc - use the first N registers as MAPped processor registers Here is the JIT optimized PASM output of $ imcc -Oj -o p.pasm

Re: Using imcc as JIT optimizer

On Thursday 20 February 2003 18:14, Leopold Toetsch wrote: Tupshin Harper wrote: Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm) Lol...what are you going to do when somebody comes along with the

Re: Using imcc as JIT optimizer

Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm) Lol...what are you going to do when somebody comes along with the unbearable example of primes.s(optimized x86 assembly), and you are forced to throw up your

Re: Using imcc as JIT optimizer

Tupshin Harper wrote: Leopold Toetsch wrote: Starting from the unbearable fact, that optimized compiled C is still faster then parrot -j (in primes.pasm) Lol...what are you going to do when somebody comes along with the unbearable example of primes.s(optimized x86 assembly), and you are

[netlabs #617] [PATCH] Optimizer fixes

# New Ticket Created by Tony Payne # Please include the string: [netlabs #617] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=617 Fixed some minor bugs w/ the Optimizer, having to do mainly with handling

Optimizer: Jeff, where are you?

G'day all. I'm working on the Optimizer (adding a new intermediate form to allow for more aggressive optimization) but mail to Jeff Goff seems to be bouncing. Does anyone know where he is? Cheers, Andrew Bromage

[Fwd: Optimizer: Jeff, where are you?]

---BeginMessage--- Andrew J Bromage wrote: G'day all. I'm working on the Optimizer (adding a new intermediate form to allow for more aggressive optimization) but mail to Jeff Goff seems to be bouncing. Does anyone know where he is? Cheers, Andrew Bromage No idea :) It's been

[PATCH] Parrot::Optimizer bugs

Enclosed patch fixes a couple of bugs in the optimizer. The first was that the parser wasn't correctly recognising register names - it needs to check for these _before_ checking for labels, or else they're incorrectly identified as labels. Strangely, this wasn't causing any problems

  1   2   >