Hi,
This patch is something I was playing around with assistance of Ian Taylor.
It seems I need bit more help though :)
It adds support for direct output of SLIM LTO files to the compiler binary.
It works as proof of concept, but there are two key parts missing
1) extension of libiberty's simple
On Wed, Sep 24, 2014 at 7:46 AM, Jan Hubicka wrote:
>
> Hi,
> This patch is something I was playing around with assistance of Ian Taylor.
> It seems I need bit more help though :)
>
> It adds support for direct output of SLIM LTO files to the compiler binary.
> It works as proof of concept, but th
Richard Biener writes:
> Btw, the patch is very hard to read as it moves (and modifies?) files
> at the same time. What's this magic "file attributes" we need?
The file attributes issue is the ELF machine number, class, OSABI,
flags, and endianness. When generating an ELF file it has to have t
On Wed, Sep 24, 2014 at 2:40 PM, Ian Lance Taylor wrote:
> Richard Biener writes:
>
>> Btw, the patch is very hard to read as it moves (and modifies?) files
>> at the same time. What's this magic "file attributes" we need?
>
> The file attributes issue is the ELF machine number, class, OSABI,
>
>
> Shouldn't -fbypass-asm be simply "mangled" by the driver? That is,
> the user simply specifies -fbypass-asm and via spec magic the driver
> substitutes this with -fbypass-asm=crtbegin.o? That way at least
> the user interface should be stable (as we're supposedly removing
> the requirement f
Jan Hubicka writes:
Nice patch.
> The implementation is pretty straighforward except for -fbypass-asm requiring
> one existing OBJ file to fetch target's file attributes from. This is
> definitly not optimal, but libiberty currently can't build output files from
> scratch. As Ian suggested, I p
On Wed, Sep 24, 2014 at 7:47 AM, Andi Kleen wrote:
>
> I wonder how hard it would be to fix simple-object to be able to create
> from scratch. From a quick look it would be mostly adding the right
> values into the header? That would need some defines per target.
It could be done, of course. It
> On Wed, Sep 24, 2014 at 7:47 AM, Andi Kleen wrote:
> >
> > I wonder how hard it would be to fix simple-object to be able to create
> > from scratch. From a quick look it would be mostly adding the right
> > values into the header? That would need some defines per target.
>
> It could be done, o
> > On Wed, Sep 24, 2014 at 7:47 AM, Andi Kleen wrote:
> > >
> > > I wonder how hard it would be to fix simple-object to be able to create
> > > from scratch. From a quick look it would be mostly adding the right
> > > values into the header? That would need some defines per target.
> >
> > It co
On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka wrote:
> Libreoffice shows that GCC needs about twice as much of system time. According
> to profiles, good part is the ugly way we pass stuff down to assembler and
> other part is memory use during the copmilation stage.
Are you using -pipe? AFAIR thi
> On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka wrote:
> > Libreoffice shows that GCC needs about twice as much of system time.
> > According
> > to profiles, good part is the ugly way we pass stuff down to assembler and
> > other part is memory use during the copmilation stage.
>
> Are you using
On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher wrote:
> On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka wrote:
>> Libreoffice shows that GCC needs about twice as much of system time.
>> According
>> to profiles, good part is the ugly way we pass stuff down to assembler and
>> other part is memor
> On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher
> wrote:
> > On Wed, Sep 24, 2014 at 6:32 PM, Jan Hubicka wrote:
> >> Libreoffice shows that GCC needs about twice as much of system time.
> >> According
> >> to profiles, good part is the ugly way we pass stuff down to assembler and
> >> othe
On Wed, Sep 24, 2014 at 11:47 PM, Ian Lance Taylor wrote:
> On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher wrote:
>> Are you using -pipe? AFAIR this still isn't the default, even on
>> GNU/Linux, but it is typically a lot faster than without.
>
> Is that true even when TMPDIR is on a ram disk?
> On Wed, Sep 24, 2014 at 11:47 PM, Ian Lance Taylor wrote:
> > On Wed, Sep 24, 2014 at 10:04 AM, Steven Bosscher wrote:
> >> Are you using -pipe? AFAIR this still isn't the default, even on
> >> GNU/Linux, but it is typically a lot faster than without.
> >
> > Is that true even when TMPDIR is on a
On Thu, Sep 25, 2014 at 12:47 AM, Ian Lance Taylor wrote:
> Is that true even when TMPDIR is on a ram disk? There's no obvious
> reason that it should be true in a parallel build. Using -pipe
> effectively constrains communication between the compiler and the
> assembler to work in PIPE_BUF bloc
16 matches
Mail list logo
