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

Hi Devang,
> > 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 :)
> 
> IMO, we should avoid using flag_unit_at_a_time here.
given DannyB's explanation that this flag exists in gcc so that glibc
works properly in spite of abusing ASM, perhaps this logic in llvm-backend
also exists to ensure that glibc works?

Ciao,

Duncan.

Duncan Sands wrote:
> Hi Devang,
>
>   
>>> 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 :)
>>>       
>> IMO, we should avoid using flag_unit_at_a_time here.
>>     
>
> given DannyB's explanation that this flag exists in gcc so that glibc
> works properly in spite of abusing ASM, perhaps this logic in llvm-backend
> also exists to ensure that glibc works?
Would changing handling of flag_unit_at_a_time solve PR2143, and allow
glibc to be compiled by llvm-gcc?

Best regards,
--Edwin

On Apr 17, 2008, at 2:26 AM, Duncan Sands wrote:
> Hi Devang,
>
>>> 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 :)
>>
>> IMO, we should avoid using flag_unit_at_a_time here.
>
> given DannyB's explanation that this flag exists in gcc so that glibc
> works properly in spite of abusing ASM, perhaps this logic in llvm- 
> backend
> also exists to ensure that glibc works?
I have no idea what this is the case or not.
>
>
> Ciao,
>
> Duncan.

On Thu, 17 Apr 2008, Duncan Sands wrote:
>>> I thought I understood why but it seems that I don't :)
>>
>> IMO, we should avoid using flag_unit_at_a_time here.
>
> given DannyB's explanation that this flag exists in gcc so that glibc
> works properly in spite of abusing ASM, perhaps this logic in llvm-backend
> also exists to ensure that glibc works?
I think it would be reasonable to turn off some of the more aggressive IPO 
xforms when -fno-unit-at-a-time is set.  That flag basically indicates 
that the code is doing something fishy, and it isn't in wide use, so I 
don't see a big problem with that.

Note that currently we can't support the glibc bug.  The issue is that we 
don't keep track of the relative positions of module-level inline asm and 
functions.  Instead, we aggregate all module-level asm together and emit 
it as a single blob.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

On Thu, Apr 17, 2008 at 1:48 PM, Chris Lattner <sabre at nondot.org>
wrote:
> On Thu, 17 Apr 2008, Duncan Sands wrote:
>
> >
> > >
> > > > I thought I understood why but it seems that I don't :)
> > > >
> > >
> > > IMO, we should avoid using flag_unit_at_a_time here.
> > >
> >
> > given DannyB's explanation that this flag exists in gcc so that
glibc
> > works properly in spite of abusing ASM, perhaps this logic in
llvm-backend
> > also exists to ensure that glibc works?
> >
>
>  I think it would be reasonable to turn off some of the more aggressive IPO
> xforms when -fno-unit-at-a-time is set.  That flag basically indicates that
> the code is doing something fishy, and it isn't in wide use, so I
don't see
> a big problem with that.
>
>  Note that currently we can't support the glibc bug.  The issue is that
we
> don't keep track of the relative positions of module-level inline asm
and
> functions.  Instead, we aggregate all module-level asm together and emit it
> as a single blob.
GCC actually does this in a very simple way.
we have flag_no_toplevel_reorder  and in this mode, simply record the
order we saw function, module level asm, and module level vars in as a
single monotonicly increasing number.
The numbers get attached to the associated nodes (IE cgraph nodes,
varpool nodes, and asmpool nodes)
We guarantee in this mode that we will output all the
vars/functions/etc that originally appeared.
(IE we do no IPA opts, etc, we just expand the functions through the
backend and perform backend opts).
When we go to output, we just sort the stuff back according to the
number and output it.