Patrick Palka writes:
> ... so it's weird that your build times are constant because building
> a thin archive is much faster than building a regular archive and
> using a thin archive should not make subsequent steps, like linking
> that archive, slower. So overall build times should be lower.
On Fri, Jul 22, 2016 at 8:02 AM, Patrick Palka wrote:
> On Fri, Jul 22, 2016 at 2:19 AM, Andrew Pinski wrote:
>> On Wed, Jul 20, 2016 at 7:11 AM, Patrick Palka wrote:
>>> On Wed, 20 Jul 2016, Bernd Schmidt wrote:
>>>
On 07/19/2016 10:20 AM, Richard Biener wrote:
> I like it. Improving
On Fri, Jul 22, 2016 at 2:19 AM, Andrew Pinski wrote:
> On Wed, Jul 20, 2016 at 7:11 AM, Patrick Palka wrote:
>> On Wed, 20 Jul 2016, Bernd Schmidt wrote:
>>
>>> On 07/19/2016 10:20 AM, Richard Biener wrote:
>>> > I like it. Improving re-build time in my dev tree is very much
>>> > welcome, and
On Wed, Jul 20, 2016 at 7:11 AM, Patrick Palka wrote:
> On Wed, 20 Jul 2016, Bernd Schmidt wrote:
>
>> On 07/19/2016 10:20 AM, Richard Biener wrote:
>> > I like it. Improving re-build time in my dev tree is very much
>> > welcome, and yes,
>> > libbackend build time is a big part of it usually (p
On Wed, 20 Jul 2016, Bernd Schmidt wrote:
> On 07/19/2016 10:20 AM, Richard Biener wrote:
> > I like it. Improving re-build time in my dev tree is very much
> > welcome, and yes,
> > libbackend build time is a big part of it usually (plus of course cc1
> > link time).
>
> Since that wasn't an en
On 07/19/2016 10:20 AM, Richard Biener wrote:
I like it. Improving re-build time in my dev tree is very much
welcome, and yes,
libbackend build time is a big part of it usually (plus of course cc1
link time).
Since that wasn't an entirely explicit ack, I'll add mine. Thank you for
doing this.
On Tue, Jul 19, 2016 at 1:20 AM, Richard Biener
wrote:
> On Tue, Jul 19, 2016 at 2:39 AM, Patrick Palka wrote:
>> On Mon, 18 Jul 2016, Segher Boessenkool wrote:
>>
>>> On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
>>> > Or, if using GNU ar, you can even use -S, if that helps
On Tue, Jul 19, 2016 at 2:39 AM, Patrick Palka wrote:
> On Mon, 18 Jul 2016, Segher Boessenkool wrote:
>
>> On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
>> > Or, if using GNU ar, you can even use -S, if that helps (after testing
>> > for it in configure, of course).
>>
>> I
On Mon, Jul 18, 2016 at 08:39:34PM -0400, Patrick Palka wrote:
> One thing that was not clear to me is whether the object file paths
> stored in a thin archive are relative or absolute paths. If they are
> absolute paths then that would be a problem due to how the build system
> moves build direct
On Mon, 18 Jul 2016, Segher Boessenkool wrote:
> On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
> > Or, if using GNU ar, you can even use -S, if that helps (after testing
> > for it in configure, of course).
>
> I meant -T. Some day I will learn how to type, promise!
Accord
Hi,
On Mon, 18 Jul 2016, Jakub Jelinek wrote:
> On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote:
> > While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is
> > when you get rid of the archive or save link time by creating a (partially)
> > linked DSO. ISTR Mi
On Mon, Jul 18, 2016 at 9:53 AM, Segher Boessenkool
wrote:
> On Mon, Jul 18, 2016 at 09:05:13AM -0400, Patrick Palka wrote:
>> On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool
>> wrote:
>> > On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
>> >> Or, if using GNU ar, you can
On Mon, Jul 18, 2016 at 09:05:13AM -0400, Patrick Palka wrote:
> On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool
> wrote:
> > On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
> >> Or, if using GNU ar, you can even use -S, if that helps (after testing
> >> for it in configure
On Mon, Jul 18, 2016 at 8:44 AM, Segher Boessenkool
wrote:
> On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
>> Or, if using GNU ar, you can even use -S, if that helps (after testing
>> for it in configure, of course).
>
> I meant -T. Some day I will learn how to type, promise
On Mon, Jul 18, 2016 at 06:35:11AM -0500, Segher Boessenkool wrote:
> Or, if using GNU ar, you can even use -S, if that helps (after testing
> for it in configure, of course).
I meant -T. Some day I will learn how to type, promise!
Segher
On Mon, Jul 18, 2016 at 2:37 PM, Jakub Jelinek wrote:
> On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote:
>> While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is
>> when you get rid of the archive or save link time by creating a (partially)
>> linked DSO. IST
On Mon, Jul 18, 2016 at 02:32:40PM +0200, Richard Biener wrote:
> While eliding ranlib sounds like a no-brainer the real benefit (I/O wise) is
> when you get rid of the archive or save link time by creating a (partially)
> linked DSO. ISTR Michael Matz has patches to do that. Whether it's
DSO?
On Mon, Jul 18, 2016 at 1:35 PM, Segher Boessenkool
wrote:
> On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote:
>> I did some digging to figure out the origin of libbackend.a. It was was
>> created to work around a command line length limit on a VAX system
>> (https://gcc.gnu.org/ml/g
Segher Boessenkool writes:
> Or, if using GNU ar, you can even use -S, if that helps (after testing
> for it in configure, of course).
BSD ar has it too.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for
On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote:
> I did some digging to figure out the origin of libbackend.a. It was was
> created to work around a command line length limit on a VAX system
> (https://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00438.html). The 1600 byte
> command line tha
On Sun, Jul 17, 2016 at 10:04:13PM -0400, Patrick Palka wrote:
> On Sun, 17 Jul 2016, David Edelsohn wrote:
>
> > On Sun, Jul 17, 2016 at 10:43 AM, Patrick Palka
> > wrote:
> > > On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote:
> > >>> Patrick Palka writes:
> > >>
> > >>> Hmm, this is
On Sun, 17 Jul 2016, David Edelsohn wrote:
> On Sun, Jul 17, 2016 at 10:43 AM, Patrick Palka wrote:
> > On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote:
> >>> Patrick Palka writes:
> >>
> >>> Hmm, this is only a problem due to command line length limits right?
> >>> Fortunately the cha
On Sun, Jul 17, 2016 at 10:43 AM, Patrick Palka wrote:
> On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote:
>>> Patrick Palka writes:
>>
>>> Hmm, this is only a problem due to command line length limits right?
>>> Fortunately the change makes the longest command line only about 10%
>>> lo
On 17/07/16 15:43, Patrick Palka wrote:
On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote:
You repeatedly are making bad assumptions and assertions without
having studied much about GCC. You assume that GNU ar is the only
archiver in use. You propose removing libbackend.a without having
inv
On Sun, Jul 17, 2016 at 9:15 AM, David Edelsohn wrote:
>> Patrick Palka writes:
>
>> Hmm, this is only a problem due to command line length limits right?
>> Fortunately the change makes the longest command line only about 10%
>> longer than the previous longest command line. With the change t
> Patrick Palka writes:
> Hmm, this is only a problem due to command line length limits right?
> Fortunately the change makes the longest command line only about 10%
> longer than the previous longest command line. With the change to
> avoid building libbackend.a altogether, the longest comma
On Sat, Jul 16, 2016 at 6:35 PM, Andrew Pinski wrote:
> On Sat, Jul 16, 2016 at 3:13 PM, Patrick Palka wrote:
>> On Sat, 16 Jul 2016, Patrick Palka wrote:
>>
>>> This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead
>>> of via "ar rc" + "ranlib", if possible. The problem with th
On Sat, Jul 16, 2016 at 3:13 PM, Patrick Palka wrote:
> On Sat, 16 Jul 2016, Patrick Palka wrote:
>
>> This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead
>> of via "ar rc" + "ranlib", if possible. The problem with the latter is
>> that it's about twice as slow as the former an
On Sat, 16 Jul 2016, Patrick Palka wrote:
> This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead
> of via "ar rc" + "ranlib", if possible. The problem with the latter is
> that it's about twice as slow as the former and it makes libbackend.a
> get written twice which is wasteful
This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead
of via "ar rc" + "ranlib", if possible. The problem with the latter is
that it's about twice as slow as the former and it makes libbackend.a
get written twice which is wasteful. On my machine this optimization
reduces rebuild
30 matches
Mail list logo
