This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: EGCS bad on loop invariant optimization ?
>>>>> «Martin», Martin von Loewis <martin@mira.isdn.cs.tu-berlin.de> wrote:
>> What about this proposal: members functions declared *const*,
>> *inlined* (i.e. g++ does see their definitions) which are *leaf*
>> functions should be subject to code-motion optimization ?
Martin> I don't know whether this is a good proposal or not; it seems to me
Martin> that constness of the data is also relevant. If you declare b and c
Martin> const in the class object example, g++ will know they won't be
Martin> modified through their addresses. Unfortunately, declaring just the
Martin> the pointer const won't help.
Even declaring data to be const changes nothing (without John's patch).
BTW, I find this restriction unnatural.
Martin> The real problem is in the implementation: I believe it is the
Martin> TREE_ADDRESSABLE flag which tells g++ whether something can live in a
Martin> register or not. Since this flag is either on or off for a given
Martin> variable, g++ doesn't know the concept 'modification through a pointer
Martin> is not possible in certain blocks'.
Seems like you are right: it appears to me (through analysis of code
g++ generates) that g++ doesn't know (or don't take into account) the
concept of constness in C++, apart the parsing stage. IMHO, this
can do nothing but to lead to poor code generation.
Martin> I have really no clue whether g++ can be changed easily to optimize
Martin> your example in a way that you like. So you either have to try
Martin> modifying it yourself,
Unfortunately, I'm not a compiler designer expert, I implement
library. Probably Mark Mitchell or Jason Merrill would like to take a
look at this (crucial) problem.
Martin> or collect convincing arguments that this is a
Martin> frequent case and absolutely deserves optimization.
In fact this kind of optimization is a prerequisite for an effectively
use of C++ in scientific computing. Actually, without this
optimization *any* attempt to implement valarray<> cannot be
convincing (compared to equivalent code written in C). There are numerous
algorithms in Linear Algebra which basically consist of
for (size_t i=0; i<N; ++i)
a[i] = arithmetic expressions involving b[i], c[i]...
where a, b, c ... are valarray<>s or classes providing array
fonctionnalities. Last but not least, this optimization is needed to
support expression template (which I used in my valarray<>
implementation).
I hope some of you will put this problem on their hot TODO lists.
-- Gaby