This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: An issue for the SC: horrible documentation quality of GCC


Hello,

>     > Perhaps, but a lot of that complexity is *needed*.  The reason that GCC
>     > has historically beaten other compilers in code quality is paying
>     > attention to important heuristics and less on "textbook" material.
>     > Sure the latter is also critical, but the pragmatics cannot be ignored.
> 
>     the problem with this approach is that you will eventually end up with
>     an uncomprehensible piece of code where everything depends on everything
>     and you cannot do a simplest change without everything else falling
>     apart.
> 
> Obviously, that's not desirable, but I don't see why it necessarily follows
> from taking a pragmatic approach to optimizations.

just from practice -- looking where did this "pragmatic approach" bring
gcc. Yes, we have might and cool "CSE" pass; but after 2 years working
on gcc, I would not dare to change a single line there because I don't
know what will happen.

>     GCSE is basically machine independent, so there should not be a need for
>     it to take machine-dependent issues into accout. These dependencies
>     should be isolated in a few later passses that can take care of the
>     issues you mention without harming each other.
> 
> Here I don't follow you.  *All* of the optimizers are written in a style
> of being machine-independent but take into account machine-dependent
> parameterizations.  Are you claiming that somehow this should not be true
> for gcse?

no -- there are optimizations that are obviously machine-dependent (like
scheduling, register allocation, peephole, combiner and whole lot of
others). Then there are optimizations that are based on some general
machine non-specific idea (like that computing one expression several
times is wrong, or that replacing variable with its constant value is
good -- CSE, GCSE, copy/const propagation, part of the loop
optimizations and some other fall into this cathegory). The sane way
how to write a compiler is to run these generic passes first, then
run machine-dependent passes that may eventually fix the mistakes
the previous optimizations have done (due to their generic ideas being
not right in some corner cases). This way we would get approximately
the same results, but in much more transparent way.

Zdenek


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]