So, PRE and other code motion/placement optimizations rely on a CFG for computation of dataflow information either implicitly (SSA form) or explicitly (non-SSA form and some SSA algorithms).
I'm going to stick to non-SSA algorithms because they are actually easier to understand the issues for.
Once you've done this, particularly the section on bitvector problems, realize that most of the properties being computed make no sense earlier than original scope of the variable, and what to do is not always apparent.
Take PRE for example, here's a simple, but crappily devised example:
int main(int argc, char argv)
{
int b;
for (int i = 0; i < 50; i++)
{
int a;
a = argc;
b = a;
}
return b;
}
(It's crappy because any value numbering/copy prop/etc would take care of this particular example)
A standard PRE is going to want to hoist a = argc out of the loop, not b = a;
But, well, it can't, because it's out of scope!
How does it know what it should do?
Should it move int a out of the loop?
It may end up inserting a stack allocation into a hot loop if it just hoists it one scope up!
Should it create a temporary?
If you allow it to create new outside-scope temporaries anyway, what's the point of keeping the scopes?
So now you have to do scope understanding and movement anyway.
Plus, in most cases, you need to construct accurate live ranges of variables anyway, and scopes do not always properly represent those.
You also have to compute what variables may share registers on your own too.
Non-renaming forms of SSA (IE that don't literally rename the temporaries) are worse here, because you can accidentally overlap live ranges of variables without too much trouble.
In any case, the basic answer is "Scopes buy you very little, and hurt a lot, because every single optimizer has to care a lot about them"
