[LLVMdev] flag_unit_at_a_time and pass scheduling in llvm-gcc
Daniel Berlin
dberlin at dberlin.org
Thu Apr 17 13:06:47 PDT 2008
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.
More information about the llvm-dev
mailing list