gt; From: "Hal Finkel"
> To: "Rafael Espíndola"
> Cc: "Renato Golin" , "gcc" , "Jan
> Hubicka"
> Sent: Tuesday, February 11, 2014 4:35:59 PM
> Subject: Re: LLVM collaboration?
>
> - Original Message -
> > From:
On 5 August 2014 16:36, Prathamesh Kulkarni wrote:
> Hi,
>I have written notes on "GCC and LLVM collaboration BOF"
> presented at the Cauldron. I would be grateful if you would
> review it for me.
Hi Prathamesh,
Sounds about right.
Other reviews, FYI:
http://llvmwee
Hi,
I have written notes on "GCC and LLVM collaboration BOF"
presented at the Cauldron. I would be grateful if you would
review it for me.
GCC and LLVM Collaboration
Author: Renato Golin
Motivation behind collaboration is to address problems that
are intrinsic to the c
On Wed, Feb 12, 2014 at 5:22 PM, Jan Hubicka wrote:
>> On Wed, 12 Feb 2014, Richard Biener wrote:
>>
>> > What about instead of our current odd way of identifying LTO objects
>> > simply add a special ELF note telling the linker the plugin to use?
>> >
>> > .note._linker_plugin '/./libltoplugi
> On Wed, 12 Feb 2014, Richard Biener wrote:
>
> > What about instead of our current odd way of identifying LTO objects
> > simply add a special ELF note telling the linker the plugin to use?
> >
> > .note._linker_plugin '/./libltoplugin.so'
> >
> > that way the linker should try 1) loading
On Wed, 12 Feb 2014, Richard Biener wrote:
> What about instead of our current odd way of identifying LTO objects
> simply add a special ELF note telling the linker the plugin to use?
>
> .note._linker_plugin '/./libltoplugin.so'
>
> that way the linker should try 1) loading that plugin, 2)
> What about instead of our current odd way of identifying LTO objects
> simply add a special ELF note telling the linker the plugin to use?
>
> .note._linker_plugin '/./libltoplugin.so'
>
> that way the linker should try 1) loading that plugin, 2) register the
> specific object with that plugi
On Tue, Feb 11, 2014 at 10:20 PM, Jan Hubicka wrote:
>> >> Since both toolchains do the magic, binutils has no incentive to
>> >> create any automatic detection of objects.
>>
>> It is mostly a historical decision. At the time the design was for the
>> plugin to be matched to the compiler, and so
- Original Message -
> From: "Rafael Espíndola"
> To: "Jan Hubicka"
> Cc: "Renato Golin" , "gcc" , "Hal
> Finkel"
> Sent: Tuesday, February 11, 2014 3:38:40 PM
> Subject: Re: Fwd: LLVM collaboration?
>
> >
> My reading of bfd/plugin.c is that it basically walks the directory and looks
> for first plugin that returns OK for onload. (that is always the case for
> GCC/LLVM plugins). So if I instlal GCC and llvm plugin there it will
> depend who will end up being first and only that plugin will be used.
> >> Since both toolchains do the magic, binutils has no incentive to
> >> create any automatic detection of objects.
>
> It is mostly a historical decision. At the time the design was for the
> plugin to be matched to the compiler, and so the compiler could pass
> that information down to the lin
> On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
> > On 11 February 2014 12:28, Renato Golin wrote:
> > > Now copying Rafael, which can give us some more insight on the LLVM LTO
> > > side.
> >
> > Thanks.
> >
> > > On 11 February 2014 09:55, Renato Golin wrote:
> > >> Hi Jan,
> > >>
>
On 2014.02.11 at 13:02 -0500, Rafael Espíndola wrote:
> On 11 February 2014 12:28, Renato Golin wrote:
> > Now copying Rafael, which can give us some more insight on the LLVM LTO
> > side.
>
> Thanks.
>
> > On 11 February 2014 09:55, Renato Golin wrote:
> >> Hi Jan,
> >>
> >> I think this is a
On 11 February 2014 12:28, Renato Golin wrote:
> Now copying Rafael, which can give us some more insight on the LLVM LTO side.
Thanks.
> On 11 February 2014 09:55, Renato Golin wrote:
>> Hi Jan,
>>
>> I think this is a very good example where we could all collaborate
>> (including binutils).
I
Now copying Rafael, which can give us some more insight on the LLVM LTO side.
cheers,
--renato
On 11 February 2014 09:55, Renato Golin wrote:
> Hi Jan,
>
> I think this is a very good example where we could all collaborate
> (including binutils).
>
> I'll leave your reply intact, so that Chandle
On 11 February 2014 16:00, Jan Hubicka wrote:
> I basically think that binutils should have a way for installed compiler to
> register a plugin and load all plugins by default (or perhaps for performance
> or upon detecking an compatible LTO object file in some way, perhaps also by
> information g
On Tuesday 11 February 2014 09:30 PM, Jan Hubicka wrote:
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more c
>
>
>
>
> On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
> >Hi Jan,
> >
> >I think this is a very good example where we could all collaborate
> >(including binutils).
> >
> >I'll leave your reply intact, so that Chandler (CC'd) can get a bit
> >more context. I'm copying him because h
On Tuesday 11 February 2014 03:25 PM, Renato Golin wrote:
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
m
Hi Jan,
I think this is a very good example where we could all collaborate
(including binutils).
I'll leave your reply intact, so that Chandler (CC'd) can get a bit
more context. I'm copying him because he (and I believe Diego) had
more contact with LTO than I had.
If I got it right, LTO today:
> 1. There IS an unnecessary fence between GCC and LLVM.
>
> License arguments are one reason why we can't share code as easily as
> we would like, but there is no argument against sharing ideas,
> cross-reporting bugs, helping each other implement a better
> compiler/linker/assembler/libraries ju
On Fri, Feb 7, 2014 at 5:07 PM, Renato Golin wrote:
> * GCC and LLVM collaboration / The Open Source Compiler Initiative
>
> With LLVM mature enough to feature as the default toolchain in some
> Unix distributions, and with the inherent (and profitable) share of
> solutions,
On 7 February 2014 23:30, Joseph S. Myers wrote:
> I think there are other closely related issues, as GCC people try to work
> around issues with glibc, or vice versa, rather than coordinating what
> might be the best solution involving changes to both components,
Hi Joseph,
Thanks for the huge
On Fri, 7 Feb 2014, Renato Golin wrote:
> For a long time already I've been hearing on the LLVM list people
> saying: "oh, ld should not accept this deprecated instruction, but we
> can't change that", "that would be a good idea, but we need to talk to
> the GCC guys first", and to be honest, nobo
On 7 February 2014 22:42, Jonathan Wakely wrote:
> The sanitizers are IMHO an impressive example of collaboration. The
> process may not be perfect, but the fact is that those powerful tools
> are available in both compilers - I think that's amazing!
I agree.
> Like the Blocks extension? :-)
S
On 7 February 2014 21:33, Renato Golin wrote:
>
> Worst still, with Clang and LLVM getting more traction recently, and
> with a lot of very interesting academic work being done, a lot of new
> things are getting into LLVM first (like the sanitizers, or some
> specialized pragmas) and we're dangerou
On 7 February 2014 22:33, Andrew Pinski wrote:
> I think it is going to called anything, it should be GNU and LLVM
> collaboration since GCC does not include binutils/gdb while LLVM
> includes the assembler/etc.
Good point. I do mean the whole toolchain.
cheers,
--renato
eft for presentations.
>
> Hi Diego,
>
> Thanks, that'd be great!
>
> A BoF would give us more time to discuss the issue, even though I'd
> like to start the conversation a lot earlier. Plus, I have a lot more
> to learn than to talk about. ;)
>
> Something
On Fri, Feb 7, 2014 at 1:53 PM, Diego Novillo wrote:
> On Fri, Feb 7, 2014 at 4:33 PM, Renato Golin wrote:
>
>> I'll be at the GNU Cauldron this year, feel free to come and discuss
>> this and other ideas. I hope to participate more in the GCC side of
>> things, and I wish some of you guys would
On Fri, Feb 7, 2014 at 1:33 PM, Renato Golin wrote:
> Folks,
>
> I'm about to do something I've been advised against, but since I
> normally don't have good judgement, I'll risk it, because I think it's
> worth it. I know some people here share my views and this is the
> reason I'm writing this.
>
BoF would give us more time to discuss the issue, even though I'd
like to start the conversation a lot earlier. Plus, I have a lot more
to learn than to talk about. ;)
Something along the lines of...
* GCC and LLVM collaboration / The Open Source Compiler Initiative
With LLVM mature enoug
On Fri, Feb 7, 2014 at 4:33 PM, Renato Golin wrote:
> I'll be at the GNU Cauldron this year, feel free to come and discuss
> this and other ideas. I hope to participate more in the GCC side of
> things, and I wish some of you guys would do the same on our side. And
> hopefully, in a few years, we
Folks,
I'm about to do something I've been advised against, but since I
normally don't have good judgement, I'll risk it, because I think it's
worth it. I know some people here share my views and this is the
reason I'm writing this.
The problem
For a long time already I've been hearing on the L
33 matches
Mail list logo
