David Edelsohn wrote:
>>> I actually think that the hybrid files should be the default. If you
>>> are willing to make invasive changes to your build environment to
>>> support two files, then you should be willing to add extra options to
>>> support that.
> IBM XLC whole program IPA mode defaul
On Sat, Oct 18, 2008 at 8:47 AM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Sat, Oct 18, 2008 at 08:33, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>> I actually think that the hybrid files should be the default. If you
>> are willing to make invasive changes to your build environment to
>> sup
On Sat, Oct 18, 2008 at 08:33, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> I actually think that the hybrid files should be the default. If you
> are willing to make invasive changes to your build environment to
> support two files, then you should be willing to add extra options to
> support tha
Diego Novillo wrote:
> On Fri, Oct 17, 2008 at 20:52, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
>
>> Andrew is correct that the reason for putting both lto and final code in
>> the same file was to do the least damage to peoples build tools. A
>> change from each invocation of gcc produce tw
Am Fri, 17 Oct 2008 14:01:35 -0600
schrieb Jeff Law <[EMAIL PROTECTED]>:
> Diego Novillo wrote:
> > On Fri, Oct 17, 2008 at 15:40, Ollie Wild <[EMAIL PROTECTED]> wrote:
> >
> >> On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo
> >> <[EMAIL PROTECTED]> wrote:
> >>> lto1 (even if -flto is not pro
On Fri, Oct 17, 2008 at 20:52, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> Andrew is correct that the reason for putting both lto and final code in
> the same file was to do the least damage to peoples build tools. A
> change from each invocation of gcc produce two files instead of one will
> se
Andrew Pinski wrote:
> On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
>> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
>>
>>
>>> If the version of GCC being used isn't compatible with the version of the IL
>>> in the object file, we
On Fri, Oct 17, 2008 at 2:15 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
>
>> If the version of GCC being used isn't compatible with the version of the IL
>> in the object file, we can just fall back on the final code.
>
On Fri, Oct 17, 2008 at 16:51, Richard Henderson <[EMAIL PROTECTED]> wrote:
> If the version of GCC being used isn't compatible with the version of the IL
> in the object file, we can just fall back on the final code.
Fair enough. But this could be provided via a flag to optionally emit
final co
Diego Novillo wrote:
We are currently emitting object files that contain both final code
and IL. I believe this is wasteful and does not really serve a useful
purpose. However, I think we started emitting hybrid object files for
some reason. Does anyone remember why?
If the version of GCC be
On Oct 17, 2008, at 1:01 PM, Jeff Law wrote:
Reality is there aren't too many non-ELF targets that matter anymore
and, IMHO, it's reasonable to demand ELF support for LTO. The only
other format that has a reasonable chance of working would be the
COFF variants anyway and the only COFF varia
On Fri, Oct 17, 2008 at 16:01, Jeff Law <[EMAIL PROTECTED]> wrote:
> I'm not really involved in the LTO stuff at all, but my recommendation would
> be to severely de-emphasize any non-ELF targets -- to the point where I'd
> say LTO is only supported on ELF targets.
Yeah, I agree. We are certainl
Diego Novillo wrote:
On Fri, Oct 17, 2008 at 15:40, Ollie Wild <[EMAIL PROTECTED]> wrote:
On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
lto1 (even if -flto is not provided) and eventually we'll need to
support archives in the reader.
Will we? I thou
On Fri, Oct 17, 2008 at 15:40, Ollie Wild <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>>
>> lto1 (even if -flto is not provided) and eventually we'll need to
>> support archives in the reader.
>
> Will we? I thought one of the main justif
On Fri, Oct 17, 2008 at 12:32 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
>
> lto1 (even if -flto is not provided) and eventually we'll need to
> support archives in the reader.
Will we? I thought one of the main justifications for implementing a
plugin architecture in the linker was to avoid ha
On Fri, Oct 17, 2008 at 15:24, Ollie Wild <[EMAIL PROTECTED]> wrote:
> At the moment, this won't work if final code is omitted. Collect2 requires
> the presence of -flto or -fwhopr before lto1 will be invoked. I'm not sure
> what the new Gold plugin does.
>
> Also, this will be problematic for s
On Fri, Oct 17, 2008 at 15:09, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Yes, so you can just link the files without any LTO at all. That is
> you can have the object files act like real object files in the
> process of compiling.
You can do that with IL-only objects too, as long as you use gcc
On Fri, Oct 17, 2008 at 12:07 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are currently emitting object files that contain both final code
> and IL. I believe this is wasteful and does not really serve a useful
> purpose. However, I think we started emitting hybrid object files for
> some r
We are currently emitting object files that contain both final code
and IL. I believe this is wasteful and does not really serve a useful
purpose. However, I think we started emitting hybrid object files for
some reason. Does anyone remember why?
Object files with just IL are not a problem for
19 matches
Mail list logo
