[LLVMdev] [patch] CodeEmitter Memory Foot Reduction

[Aaron Gray]

2009/7/16 Daniel Dunbar <daniel at zuster.org>

> On Thu, Jul 16, 2009 at 10:04 AM, Aaron
> Gray<aaronngray.lists at googlemail.com> wrote:
> > 2009/7/16 Chris Lattner <clattner at apple.com>
>  >> Whats Daniels approach, does he have any online documentation or code,
> do
> >> you have an email address so I may talk to him.
> >>
> >> Take a look at how asmprinters work
> >> in include/llvm/Target/TargetRegistry.h .  If you have specific
> questions,
> >> llvmdev is a great place to ask them.
> >
> >
> >
> > Okay I will take a look.
>
> I don't have any documentation yet other than the doxygen comments
> (some will be added at least before 2.6), but the basic idea is that
> there is one global Target instance per target, and targets register
> optional components via initialization functions (which can be called
> via static constructors, or explicitly by the client).
>
> Clients of the targets simple request a Target, which will always be
> linked in, and look to see if the optional functionality is present
> (i.e. was linked in).
>

Okay so features must be linked in rather than availiable from dynamicly
linked libraries.

This does not really help.

Sorry,

Aaron


>
>  - Daniel
>
> > Aaron
> >
> >>
> >> -Chris
> >>
> >>
> >> Aaron
> >>
> >> 2009/7/16 Chris Lattner <clattner at apple.com>
> >>>
> >>> On Jul 15, 2009, at 9:01 AM, Aaron Gray wrote:
> >>>>
> >>>> Chris,
> >>>>
> >>>> If you/we do not like this code, then the alternatives are :-
> >>>> 1) Leave as is, which I would not suggest.
> >>>> 2) Revert to using MachineCodeEmitter like mechanics with virtual
> >>>> extend() method to allow rebuffering with ObjectCodeEmitter providing
> the
> >>>> memory management.
> >>>> 3) Don't really know of any other alternatives :)
> >>>>
> >>>> 2 maybe the best compromise option. Its easy to code, removes
> templating
> >>>> from the CodeEmitters, and is virtually transparent to our other DOE
> work.
> >>>> The only thing it does not write via a BinaryObject object, so we
> loose that
> >>>> functionality.
> >>>
> >>> Hi Aaron,
> >>>
> >>> I'm sorry for not getting back to you sooner.  I work fairly LIFO and
> the
> >>> craziness that has happened since your emails have distracted me.
> >>>
> >>> One problem with this patch is that (for example) X86TargetMachine.cpp
> >>> refers to the "createX86ObjectCodeEmitterPass" symbol, which forces the
> code
> >>> emitter to object code emitter to be linked into the X86 target module.
> >>>  There is still no way to create a JIT without two copies of the code
> >>> emitter template.  I believe that aligning this work with Daniels work
> to
> >>> make the targets more modular would be straight forward.  Are you
> willing to
> >>> do this?
> >>>
> >>> This patch keeps around the templates, which I really don't like.
> >>>  However, this is better than what is in mainline, so it seems like a
> >>> reasonable step to me if you really really want to do this.  However, I
> >>> still don't understand why you're unwilling to make the CodeEmitter be
> a
> >>> virtual base class instead of a template!
> >>>
> >>> -Chris
> >>
> >>
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090716/72784c99/attachment.html>