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: proposal for compilation unil wide alias analyis


    In other words, I'd expect that having the tree-to-RTL expanders take
    GENERIC -- or even near-generic with callbacks into the front end to
    expand non-GENERIC bits to GENERIC on the fly -- would be a win over
    forcing everything to be converted to SSA GIMPLE first.  The fewer
    passes we make over the tree structure, the better.

Do you mean GENERIC or GIMPLE here?  I thought the idea was to make the RTL
expanders accept only GIMPLE.  That will not only make them smaller but
perhaps faster.  I agree about going into SSA, but I think the cost of going
all the way into GIMPLE is small and saving it isn't worth complicating the
RTL expanders.  (Although it may not need to be "full GIMPLE": there's
no point in creating the temporary for (I + J) * K, for example, in -O0).

    The Laffer curve argument (we can remove so much code in the
    optimizers so quickly that generating the code will actually be
    faster) seems to me like it is one that should be proven
    experimentally before we commit to it.

I agree, but don't see it as a single issue: I see it as an independent
decision for a number of different optimizers.

    (For reference, I've seen compilers that had two completely different 
    code generators: one for optimized code and one for unoptimized code.  
    They basically split after front end processing into completely 
    different bodies of code.  The unoptimized code version was very dumb, 
    but very fast.)

GCC used to do this in part.  We'd use a separate register allocator,
stupid.c, for the -O0 case.  This was eliminated in GCC 3 and we took a
substantial hit on -O0 compilation speed as a result.


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