split local

[nomaddo]

I am planning to split local into two variables

• local (really local in a basic block)
• global (shared by basic blocks)

The name global conflict the name of global variables shared by some functions, so it is considerable to change it.

The reason I want to change it is for ease of writing optimizations.
Currently, it is difficult to write optimizations because every variable may be referred by other basic blocks.
By split them into local and global, we may implement optimizations with ease.
Yes, BasicBlock::isLocallyLimited can checi it. But I am wondering it is always right.

@doe300 What do you think about this?

[doe300]

Great idea!
I thought of this too a few times, but never came up with a concept to do this correctly.
This would also simplify and speed-up register-association greatly.

For the naming, if we can't come up with a better name, I think BlockLocal and MethodLocal, e.g. as two sub-classes of Local should do.

One issue we need to consider is converting between method-wide or block-wide locals:

• E.g. for hoisting instructions out of loops
• Also the reverse direction (though not strictly necessary, but very useful), we need to convert them either automatically (if all uses within a single block) or via some kind of optimization/normalization step

Another problem is the generation of locals:

• How does a front-end know whether a local is only used within a single block?

[nomaddo]

@long-long-float, do you have a idea about this?

[nomaddo]

How does a front-end know whether a local is only used within a single block?

It's okey to emit instructions, which are all global variables first.
By applying analysis of global-to-local, these should be converted to local.

This method is straightforward: Visit every basic block to know what variables must be global.

label1:
iadd c, a, b   // `a` and `b` is read before defining it in this basic block, should be global
iadd d, c, a

In this case, a and b must be global, but we need more analysis about c and d.
If no requirement of c and d exist, we can change c and d to local.

[doe300]

This method is straightforward: Visit every basic block to know what variables must be global.

We could use the new analysis/LivenessAnalysis for this, it gives the Locals used by a basic block but not written in the same block before usage as side-effect. Or we could use the LocalUsageAnalysis (in the same files) which determines for every basic block the "input" and "output" locals.