Re: LTO progress indicator
> On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc > wrote: > > > > >> Is there any change to have some LTO progress indicator information in > > upstream GCC output? Do I need to report a bug? > > Is there any chance ... (sorry for typo) > > You can add -Q to the command line which makes GCC output some sort > of progress indication. Otherwise no - we do not really know how long a > compile will take so a true progress indicator isn't possible. For ltrans we do make estimate used by partitioning, so for large projects that consits of many functions we may be able to do some sort of progress info on ltrans stage. But indeed, when waiting for large copmiles, I use -Q to make myself entertained :) Honza
Re: LTO progress indicator
Hi On Sun, Sep 15, 2024 at 11:59 AM Jan Hubicka wrote: > > On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc > > wrote: > > > > > > >> Is there any change to have some LTO progress indicator information > in > > > upstream GCC output? Do I need to report a bug? > > > Is there any chance ... (sorry for typo) > > > > You can add -Q to the command line which makes GCC output some sort > > of progress indication. Otherwise no - we do not really know how long a > > compile will take so a true progress indicator isn't possible. > > For ltrans we do make estimate used by partitioning, so for large > projects that consits of many functions we may be able to do some sort > of progress info on ltrans stage. > > But indeed, when waiting for large copmiles, I use -Q to make myself > entertained :) > Actually my script on the first email creates a progressbar from /tmp/*ltrans* files. Thank you for your answers
Re: LTO progress indicator
Hi, and thank you for your answer.
Is there an option to have LTO in the final GCC, but without using LTO in
compiling GCC itself?
On Sun, Sep 15, 2024 at 9:00 AM Richard Biener
wrote:
> On Sat, Sep 14, 2024 at 1:17 PM Ghorban M. Tavakoly via Gcc
> wrote:
> >
> > >> Is there any change to have some LTO progress indicator information in
> > upstream GCC output? Do I need to report a bug?
> > Is there any chance ... (sorry for typo)
>
> You can add -Q to the command line which makes GCC output some sort
> of progress indication. Otherwise no - we do not really know how long a
> compile will take so a true progress indicator isn't possible.
>
> RIchard.
>
> > On Sat, Sep 14, 2024 at 2:41 PM Ghorban M. Tavakoly
> > wrote:
> >
> > > I build GCC from git repo regularly. Unfortunately my system is old
> and a
> > > full GCC build takes about 30 hours. I learnt that the maximum build
> time
> > > spent is in LTO. I wrote a simple shell script to check LTO progress:
> > >
> > > #!/bin/sh
> > >
> > > AWKP='
> > > BEGIN { RS=" " ; w = COLS - 19 }
> > > END { progressbar(current, total) }
> > >
> > > /ltrans.o/ { current++ }
> > > /ltrans[0-9]+.o/ { total++ }
> > >
> > > function progressbar(current, total) {
> > > if (total == 0) {
> > > printf(" %s Waiting!\r", substr("|/-\\", 1 + systime() % 4, 1))
> > > return
> > > }
> > > progress = current / total
> > > prefix = sprintf(" %d/%d [", current, total)
> > > suffix = sprintf("] %.1f%%", 100 * progress)
> > > width = COLS - length(prefix) - length(suffix)
> > > bar = ""
> > > for (col = 0; col < width; col++)
> > > bar = bar (col / width < progress ? "=" : " ")
> > > printf("%s%s%s\r", prefix, bar, suffix)
> > > }'
> > >
> > > while [ 1 ] ; do
> > > echo $(ls /tmp/*ltrans* 2> /dev/null) | gawk -v COLS=`tput cols`
> > > "$AWKP"
> > > sleep 1
> > > done
> > >
> > > Is there any change to have some LTO progress indicator information in
> > > upstream GCC output? Do I need to report a bug?
> > >
> > > I need LTO. Is there a way to have LTO in GCC, without LTOing the GCC
> > > itself? This way my builds will be many times faster.
> > >
> > > Regards and thanks to your awesome compilers
> > >
> > > --
> > > *Ghorban M. Tavakoly*
> > > Phone number: +98 (902) (2²⁰+2¹⁹+2¹⁸+…+2²+2¹+2⁰)
> > >
> > >
>
Re: [RFC] Return Value Propagation in IPA-CP
> Ping (https://gcc.gnu.org/pipermail/gcc/2024-August/244625.html).
Hi,
> > * Proposed Solution *
> >
> > * Extending IPA-CP:
> >
> > 1. Add return jump function data structures
> > - This involves updating ipa_node_params to contain information
> > regarding the
> > return statements of the function, namely the lattice and the jump
> > function
> > describing the return value, where both use existing data structures.
> > - The ipa_node_params class is reused to avoid introducing a new class
> > and a
> > corresponding function_summary type, though it is trivial to add if
> > deemed
> > a better solution. The ipa_return_value_summary class may also be a
> > good
> > place for this information, however using it would involve moving it
> > from
> > ipa-prop.cc to ipa-prop.h.
Yes, I think the jump functions for return values are not realy
different from jump functions for call parameters, so indeed we want to
reuse same datatstructure.
We want to track all the usual stuff we do (value ranges, constant
values, known fields in structures...)
In longer run we will want to extend jump functions to represent
properties like "value returned by call X is passed as argument n to
call Y". But for the first version we probably do not need to worry
about this.
> > - Additionally, ipa_edge_args is updated to track whether or not it is a
> > callgraph edge originating from a return statement. This enables the
> > propagation of information in the WPA phase.
What you exactly mean by callgraph edge originating from return
statement?
> >
> > 2. LGEN
> > - Set up return jump functions for each function similar to the parameter
> > jump function. When it cannot be conclusively determined that one
> > formal
> > parameter is always returned (such as conditionally returning either of
> > two), the jump function is marked as invalid.
> > - This involves looking through phi nodes when return statements of
> > conditional branches are merged into a single exit block. Note that
> > returning a call expression does not count towards invalidating the
> > information for that function.
The analysis is essentially the same as for function parameters, just
looking at the return statements, so I think most of code can be shared
with what we have.
> >
> > 3. WPA
> > - Implement return value information propagation. It is not possible to
> > do
> > this in the existing propagate_constants_topo function, because it
> > iterates
> > in reverse postorder i.e. from caller to callee. However return value
> > propagation needs to be done from callee to caller, thus there is a
> > need to
> > iterate in a postorder fashion.
> > - The lattice values are initialized using the jump functions computed
> > in the
> > LGEN phase. These values are then propagated over the callgraph.
> > - The existing lattices are reused, with three possible values like
> > usual.
> > The possible values are:
> >
> > return_lattice -> { TOP, param_decl, BOTTOM }
> >
> > where TOP and BOTTOM are defined as usual. param_decl refers to the
> > tree of
> > either the parameter declaration or its type, whichever is available.
> > The
> > meet operator is defined as usual for TOP and BOTTOM. When both are
> > param_decl, the following meet operation is defined:
> >
> > meet(x, y) = x if x == y, BOTTOM otherwise
> >
> > - Finally, nodes to which no information could be propagated are marked
> > as
> > BOTTOM and the BOTTOM value is propagated to a fixed-point. This is
> > required
> > when information about a caller has been inferred but not about one of
> > its
> > callees. For example:
> >
> > extern int foo(int);
> >
> > __attribute__((noinline))
> > int bar (int z)
> > {
> > return foo (z);
> > }
> >
> > __attribute__((noinline))
> > int baz (int z)
> > {
> > return z;
> > }
> >
> > int quux (int z)
> > {
> > if (z & 1)
> > return bar (z);
> > else
> > return baz (z);
> > }
> >
> > In this case, after propagation, the lattice values look like the
> > following:
> > - bar/ret -> TOP
> > - baz/ret -> baz/0 (first parameter being returned)
> > - quux/ret -> quux/0 (lattice partially inferred from baz)
> >
> > Here, we are not able to infer any information about bar because it
> > calls a
> > function foo that is not visible to the compiler. If we only set bar to
> > BOTTOM and do not propagate this BOTTOM value to quux, we will
> > incorrectly
> > infer that quux always returns its 1st parameter.
Yep, it is essentially a simple dataflow. propagate_constants_topo
can probably be still saved by simply considering calls with interesting
return functions as bi-directional for discovery of strongly connected
component.
Somewhat tricky will be implementing cloning heuristi
Re: LTO progress indicator
"Ghorban M. Tavakoly via Gcc" writes: > > I need LTO. Is there a way to have LTO in GCC, without LTOing the GCC > itself? This way my builds will be many times faster. LTO can be used without LTOing gcc itself. It is normally built by default if the target supports it. -Andi
gcc-15-20240915 is now available
Snapshot gcc-15-20240915 is now available on https://gcc.gnu.org/pub/gcc/snapshots/15-20240915/ and on various mirrors, see https://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 15 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision d204bee388d74a6895da15a1027a64a8c4ea4fbb You'll find: gcc-15-20240915.tar.xz Complete GCC SHA256=9a5c95bb4b7d0c61e6837a660a2c1171e281372bb46e9cfeb110041702946bad SHA1=e7306c2c19556b850a64eb64e7cd8f07b88e1b9c Diffs from 15-20240908 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-15 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Resurrect PowrPC SPE port feasible?
Hello, the PowerPC SPE port was obsoleted in GCC 8. It was moved from the general PowerPC directory (gcc/config/rs6000) to a separate directory (gcc/config/powerpcspe). In GCC 9, it was removed due to a lack of maintenance. I am not a compiler expert, so I have no idea how much work it is to keep a back-end up to date. How much work would it be roughly to bring the PowerPC SPE port from GCC 8 to the current version? Is this in the range of person weeks, months, years? Kind regard, Sebastian -- embedded brains GmbH & Co. KG Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
