"The compiler does not understand the required high level result almost always."
Depends heavily on the language and code we are talking about.
For C++, there are plenty of compilers that can replace C++ standard library calls and usage with faster, more optimal, C++ library calls and usage.
That's because it is possible to understand the guarantees needed.
That's about as far as you can get in a language like C++. You can do complex idiom recognition (IE recognize handwritten sorts, whatever) but it's usually not worth it.
Now obviously, there are languages that express invariants/contracts/etc that make this type of optimization much easier to do.
"They typically fail as devising such structure safely from low level code is a really hard problem."
Actually, the safety part is easier than the allowed part if you are trying to split them.
But usually they are the same thing - the language does not allow it, therefore it is unsafe.
It is generally easy and well understood how to analyze and know what set of preconditions any particular transform safe, and even if you can't prove it statically, you can insert runtime checks to make sure the preconditions hold. This generalizes very well. It's just not worth it most of the time.
This is why we focus on subsets like loops, and things like polyhedral loop opts, etc, have complex cost models that try to take into account the cost of dynamic checks, etc.
(I spent years funding and talking to researchers about this)
Depends heavily on the language and code we are talking about. For C++, there are plenty of compilers that can replace C++ standard library calls and usage with faster, more optimal, C++ library calls and usage. That's because it is possible to understand the guarantees needed.
That's about as far as you can get in a language like C++. You can do complex idiom recognition (IE recognize handwritten sorts, whatever) but it's usually not worth it.
Now obviously, there are languages that express invariants/contracts/etc that make this type of optimization much easier to do.
"They typically fail as devising such structure safely from low level code is a really hard problem."
Actually, the safety part is easier than the allowed part if you are trying to split them.
But usually they are the same thing - the language does not allow it, therefore it is unsafe.
It is generally easy and well understood how to analyze and know what set of preconditions any particular transform safe, and even if you can't prove it statically, you can insert runtime checks to make sure the preconditions hold. This generalizes very well. It's just not worth it most of the time.
This is why we focus on subsets like loops, and things like polyhedral loop opts, etc, have complex cost models that try to take into account the cost of dynamic checks, etc.
(I spent years funding and talking to researchers about this)