Ben Morrow wrote:
Quoth [EMAIL PROTECTED]:
RESUMABLE: func_that_might_loop_through_cc()
possibly accompanied with another markup of the function call that
loops back.
That can't work, because *any* function might loop back, unless you want
to analyse the entire logic flow of the called funct
At 5:36 PM -0800 11/19/04, Bill Coffman wrote:
Another thing I'd like to do, is throw in is a randomizer, to change
the way the allocator assigns registers. Considering all the cruft
that was uncovered when the algorithm was changed, it might be a good
idea to have a debug feature that selects reg
On Thu, 18 Nov 2004 08:13:02 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Bill Coffman <[EMAIL PROTECTED]> wrote:
> > ps: I'm making progress on grokking the cfg and register renaming
> > stuff. Will let you know.
>
> This needs an SSA graph of the data flow?
Static Single-Assignment (I h
Dan Sugalski wrote:
If the point is to direct the allocator to flush temps and start fresh,
then we should just do it:
.flushtemps
The point basically is to insert a loop into the CFG. When we have
foo()
...
bar()
which is a linear control flow through these basic blocks, we need:
in
At 8:26 AM +0100 11/18/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Exceptions and continuations should be the same problem -- the target
is the start of a basic block. (Well, more than that, as they're
places where calling conventions potentially kick in) This means the
i
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Since I understand the item about allocating registers between sub
> calls, I can probably implement that change, as I work through the
> control flow/data flow analysis.
I've no resynced pending changes with the old allocator and committed
these changes.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions and continuations should be the same problem -- the target
> is the start of a basic block. (Well, more than that, as they're
> places where calling conventions potentially kick in) This means the
> instruction immediately after a sub call start
Bill Coffman <[EMAIL PROTECTED]> wrote:
> Since I understand the item about allocating registers between sub
> calls, I can probably implement that change, as I work through the
> control flow/data flow analysis.
This is already implemented, parts of it are in CVS.
> Sounds like everything else
> >* [NEW] If register 15 or below is used, it should be cleared out,
> >ZEROED, after it's last use and before the next sub call. This is for
> >security reasons. Obviously, these registers will not be the first
> >choice to use.
>
> Nope -- this isn't the job of the register allocator. We aren
At 2:02 PM -0800 11/17/04, Bill Coffman wrote:
So to generalize. The following registers are available, under the
following conditions:
* [NEW] If register 15 or below is used, it should be cleared out,
ZEROED, after it's last use and before the next sub call. This is for
security reasons. Obvio
So to generalize. The following registers are available, under the
following conditions:
* Registers R16-R31 are always available for the allocator.
* Registers R0-R15 are available between sub calls. That is, for any
symbol, whose life range does not cross a subroutine. (This implies
that all
At 10:12 PM +0100 11/17/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
All registers are preserved, but some of these registers are used,
either by implict opcodes or as return values.
Erm, no. Unused registers in the 0-15 ra
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
>>All registers are preserved, but some of these registers are used,
>>either by implict opcodes or as return values.
> Erm, no. Unused registers in the 0-15 range are explicitly garbage:
It was about usa
At 2:14 PM +0100 11/17/04, Leopold Toetsch wrote:
Works fine *except* for the .flatten_arg directive. This directive
takes an argument array and expands the array contents to function
arguments in consecutive parrot registers. E.g.
.arg a=> P5
.flatten_arg array=> P6, P7,
At 7:34 PM +0100 11/17/04, Leopold Toetsch wrote:
Bill Coffman <[EMAIL PROTECTED]> wrote:
On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
I've now (locally here) extended Bill Coffman's register allocator by
one subroutine that actually decides to use non-volatiles
Bill Coffman <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> I've now (locally here) extended Bill Coffman's register allocator by
>> one subroutine that actually decides to use non-volatiles or volatiles
>> according to pdd03. All vari
On Wed, 17 Nov 2004 14:14:18 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I've now (locally here) extended Bill Coffman's register allocator by
> one subroutine that actually decides to use non-volatiles or volatiles
> according to pdd03. All variables that are live around a subroutine call
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
[ setp_ind troubles ]
I've found a way to force allocation to R16..R31 in the presence of this
opcode.
leo
I've now (locally here) extended Bill Coffman's register allocator by
one subroutine that actually decides to use non-volatiles or volatiles
according to pdd03. All variables that are live around a subroutine call
are e.g. allocated from R16..R31.
Variables not alive around a call (temps) are a
19 matches
Mail list logo
