[Apologies if you receive this twice,
No problemm, the duplicate filter in procmail takes care of it.
On Sat, Feb 08, 2003 at 12:19:35PM +0100, Leopold Toetsch wrote:
When we want these kind of branches, then they must be more high level, defining all possible branch targets, e.g. like a switch statement.
I think all that means that I *can* specify a set of labels that the
instruction might jump to, and guarantee that if it jumps to anywhere
else that it won't affect any registers.
I think, that should be enough to allocate registers in a save way. Though it might not the most efficient way to do it. It really depends on the complexity of such code pieces. When regex code is intersparsed with "normal" code, it will be for sure not be possible to reuse registers, when the control flow is not known.
... For now, I'm prototyping using a heavyweight mechanism. If that gets to be too unwieldy, maybe I'll take a look at implementing something like
bsr $I0 = _label1 | _label2 | @REGISTER_PRESERVING_LOCATION@
(Ignore the syntax!). It's only needed for imcc, right? (I wouldn't need to propagate it through to the JIT or anything, would I?)
Its for the register allocator. But it really depends on calling conventions. When the bsr's do a saveall/restoreall and arguments are passed on stack then it's no problem, the "bsr" is a "noop" then in terms of CFG. When the bsr's have e.g. pdd03 calling conventions, then each possible control flow has to be tracked and allocated registers must match.
How is invoke handled? Is it assumed to always use the full PDD06 calling conventions?
s/06/03/ - No. When code is only called internally, it can use any calling convention, that fits best.
leo
