llvm dev - Apr 2008 - [LLVMdev] flag_unit_at_a_time and pass scheduling in llvm-gcc

In llvm-backend.cpp I see:

    if (optimize > 1) {
      if (flag_inline_trees > 1)                // respect
-fno-inline-functions
        PM->add(createFunctionInliningPass());  // Inline small functions
      if (flag_unit_at_a_time && !lang_hooks.flag_no_builtin())
        PM->add(createSimplifyLibCallsPass());  // Library Call Optimizations

      if (optimize > 2)
        PM->add(createArgumentPromotionPass()); // Scalarize uninlined fn
args
    }

Shouldn't createFunctionInliningPass and createArgumentPromotionPass only be
called if flag_unit_at_a_time is true?  As far as I can see flag_unit_at_a_time
is used to control whether inter-procedural/whole-module passes are scheduled.

Thanks,

Duncan.

On Apr 15, 2008, at 11:49 PM, Duncan Sands wrote:
> As far as I can see flag_unit_at_a_time
> is used to control whether inter-procedural/whole-module passes are  
> scheduled.

You can do inlining even when flag_unit_at_a_time is off. And one can  
enable unit-at-a-time without enabling any optimizations.  The unit-at- 
a-time is not meant to select optimization passes, though it may  
influence selection.

Originally, this flag instructs gcc to parse entire source file before  
producing code. I am told that originally gcc worked on one statement  
at a time (stmt->parse->optimize->codegen->next-stmt). Later on it
was
enhanced to work on a function at a time. Next logical step was to  
work on a source file at a time. IIRC, the flag was required because  
some of the lang. FE produced parsed trees caused huge amount of  
memory pressure during code generation making unit-at-a-time not  
suitable for all languages.

-
Devang

On Wed, Apr 16, 2008 at 1:13 PM, Devang Patel <dpatel at apple.com>
wrote:
>
>  On Apr 15, 2008, at 11:49 PM, Duncan Sands wrote:
>
>  > As far as I can see flag_unit_at_a_time
>  > is used to control whether inter-procedural/whole-module passes are
>  > scheduled.
>
>
>  You can do inlining even when flag_unit_at_a_time is off. And one can
>  enable unit-at-a-time without enabling any optimizations.  The unit-at-
>  a-time is not meant to select optimization passes, though it may
>  influence selection.
>
>  Originally, this flag instructs gcc to parse entire source file before
>  producing code. I am told that originally gcc worked on one statement
>  at a time (stmt->parse->optimize->codegen->next-stmt). Later
on it was
>  enhanced to work on a function at a time. Next logical step was to
>  work on a source file at a time. IIRC, the flag was required because
>  some of the lang. FE produced parsed trees caused huge amount of
>  memory pressure during code generation making unit-at-a-time not
>  suitable for all languages.
>
Everything is right except for your last sentence or two :)
The real reason for flag_unit_at_a_time was that some
programs/libraries (glibc in particular) required the top level ASM
statements to be output in the same order and place they appear in the
source file (they were using it to change sections, etc).  The
original unit_at_a_time mode did not do this, so we needed a flag to
turn it off in order not to break glibc.
At some point we gave up hope that they would change their ways and
implemented tracking the order of the top level asm statements and
outputting them relative to where they appear in the original source
file.

Hi Devang,
> You can do inlining even when flag_unit_at_a_time is off. And one can  
> enable unit-at-a-time without enabling any optimizations.  The unit-at- 
> a-time is not meant to select optimization passes, though it may  
> influence selection.
this flag is used quite a bit in llvm-backend.cpp, for example:

    if (flag_unit_at_a_time) {
      PM->add(createGlobalOptimizerPass());       // Optimize out global vars
      PM->add(createGlobalDCEPass());             // Remove unused fns and
globs
      PM->add(createIPConstantPropagationPass()); // IP Constant Propagation
      PM->add(createDeadArgEliminationPass());    // Dead argument
elimination
    }

I thought I understood why but it seems that I don't :)

Ciao,

Duncan.