llvm dev - Jul 2009 - [LLVMdev] [patch] CodeEmitter Memory Foot Reduction

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).

 - 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
>
>

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>

On Thu, Jul 16, 2009 at 11:43 AM, Aaron
Gray<aaronngray.lists at googlemail.com> wrote:
> 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.
Library features do not have to be linked in, however that is the
mechanism we want to use for the core LLVM libraries. The registry
mechanism itself doesn't care whether it is called via an
initialization function called directly, or a static constructor (etc)
run during the loading of a dynamic library.

 - Daniel