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
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 had to look
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
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.
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
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:
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
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
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 variables that
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 or
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 usabalitiy
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
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 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.
* [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't
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 is
16 matches
Mail list logo
