Looking for a new dragonegg maintainer

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Looking for a new dragonegg maintainer

Duncan Sands
Hi all, I just don't have time to look after dragonegg properly any more, so I'm
looking for someone to care over the care and feeding of this project.  This not
only means ensuring that it continues to compile and work, it also means

- making sure dragonegg makes use of new LLVM features (eg struct TBAA)
- making sure it works with new versions of GCC, and supports interesting new
   GCC features
- being involved in discussion of changes to LLVM, to ensure they are well
   adapted to the needs of dragonegg.  For example, it would have been better if
   struct TBAA had been designed to be more generic.  But I wasn't there to point
   out the needs of other languages like Ada, Fortran and Go, so it just ended up
   being designed directly for C-like languages (which are rather simple).  This
   is a natural outcome if the only people giving input are those working on
   clang.
- fixing the main problems of dragonegg:
   (a) debug info is poor.
   (b) ABI support is poor.  Dragonegg has it's own not very good ABI
       implementation for each platform.  Yet GCC has an abstract interface
       for ABI information.  The GCC function call lowering logic is generic,
       and just queries the ABI interface.  Dragonegg should just use that.
       The related problem right now is that, since gcc-4.7, GCC considers all
       function pointer types to be equivalent, and throws away any casts.
       Since dragonegg's ABI lowering looks at the function pointer type to
       decide how many parameters a function gets etc, this means it will get
       it wrong if the type was cast in the original code (because "fold" will
       have thrown the cast away).
- keeping an eye on the buildbots and investigating problems.

Any takers?

Best wishes, Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Looking for a new dragonegg maintainer

Alp Toker

On 14/11/2013 09:56, Duncan Sands wrote:
> Hi all, I just don't have time to look after dragonegg properly any
> more, so I'm
> looking for someone to care over the care and feeding of this project.

Hi Duncan,

I still remember watching in awe the unending commits you made in 2009
to make dragonegg a reality.

I'd just like to say thank you for the great work you've done to
maintain the project.

Cheers,
Alp.



>   This not
> only means ensuring that it continues to compile and work, it also means
>
> - making sure dragonegg makes use of new LLVM features (eg struct TBAA)
> - making sure it works with new versions of GCC, and supports
> interesting new
>   GCC features
> - being involved in discussion of changes to LLVM, to ensure they are
> well
>   adapted to the needs of dragonegg.  For example, it would have been
> better if
>   struct TBAA had been designed to be more generic.  But I wasn't
> there to point
>   out the needs of other languages like Ada, Fortran and Go, so it
> just ended up
>   being designed directly for C-like languages (which are rather
> simple).  This
>   is a natural outcome if the only people giving input are those
> working on
>   clang.
> - fixing the main problems of dragonegg:
>   (a) debug info is poor.
>   (b) ABI support is poor.  Dragonegg has it's own not very good ABI
>       implementation for each platform.  Yet GCC has an abstract
> interface
>       for ABI information.  The GCC function call lowering logic is
> generic,
>       and just queries the ABI interface.  Dragonegg should just use
> that.
>       The related problem right now is that, since gcc-4.7, GCC
> considers all
>       function pointer types to be equivalent, and throws away any casts.
>       Since dragonegg's ABI lowering looks at the function pointer
> type to
>       decide how many parameters a function gets etc, this means it
> will get
>       it wrong if the type was cast in the original code (because
> "fold" will
>       have thrown the cast away).
> - keeping an eye on the buildbots and investigating problems.
>
> Any takers?
>
> Best wishes, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

--
http://www.nuanti.com
the browser experts

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev