> 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
> 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 ma
Hello,
we are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Prague, Czech Republic, on September 14-16, 2024.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2024
Like last year, we are having to charge for
Hello,
we are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Prague, Czech Republic, on September 14-16, 2024.
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2024
Like last year, we are having to charge for
> > The problem is testing. If gcc would re-number the basic blocks then
> > tests comparing hard-coded test paths would break, even though the path
> > coverage itself would be just fine (and presumably the change to the
> > basic block indices), which would add an unreasonable maintenance
> > bur
> On Dez 01 2023, Richard Biener via Gcc wrote:
>
> > Hmm, so why's it then referenced and not "GCed"?
>
> This has nothing to do with garbage collection. It's just the way
> libgcc avoids having too many source files. It would be exactly the
> same if every function were in its own file.
THe
> Hello,
Hi,
> I have almost completed the output of relocation entries. The only thing
> that remains is to output the corresponding symbols in .symtab. In my
> current design, I store the info about relocation entry and the symbol
> name. However, the problem I am facing with this approach is tha
> Hello,
> I am working on a project to produce the LTO object file from the compiler
> directly. So far, we have
> correctly outputted .symtab along with various .debug sections. The only
> thing remaining is to
> correctly output attribute values and their corresponding values in the
> .debug_inf
> Hi!
>
> On 2023-09-07T19:00:49-0400, James Hu via Gcc wrote:
> > I noticed that adding incremental LTO was a GSoC project that was not
> > claimed this cycle (
> > https://summerofcode.withgoogle.com/programs/2023/organizations/gnu-compiler-collection-gcc).
> > I was curious about working on th
> > If I comment it out as above patch, then O3/PGO can get 16% and 12%
> > performance
> > improvement compared to O2 on x86.
> >
> > O2 O3 PGO
> > cycles 2,497,674,824 2,104,993,224 2,199,753,593
> > instructions1
> Hi,
>
> I have added the patch (
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623379.html ) on the
> devel/bypass-asm branch.
> Although I am able to build using the --disable-bootstrap option but while
> doing a bootstrapped build, I am getting these errors ( as warnings while
> doing
> > > +simple_object_write_add_symbol(simple_object_write *sobj, const char
> > *name,
> > > +size_t size, unsigned int align);
> >
> > Symbols has much more properties in addition to sizes and alignments.
> > We will eventually need to get dwarf writting, so we will need to
> > support them. Howev
> Hi,
Hi,
I am sorry for late reaction.
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." So as a first step, I am adding .symtab along with
> __gnu_lto_slim symbol into it so that at a later stage, it can be
> recognized that this object file has been produc
> Hi Everyone,
Hello,
> I am working on the GSOC project "Bypass Assembler when generating LTO
> object files." My mentors and I have decided to work on the ELF files
> first, so I will add .symtab along with the symbol __gnu_lto_slim to
> the ELF file as a first step.
> When I was going through th
ld be better too, I think grammar is not critical here.
Thanks a lot for making and submitting the proposal.
Honza
>
> On Tue, 4 Apr 2023 at 15:55, Jan Hubicka wrote:
>
> > Hello,
> > > Thanks, Jan for the Reply! I have completed a draft proposal for this
> > > pr
ing
implementation. Adding support for other object formats can be done
incrementally.
Honza
>
> On Tue, 4 Apr 2023 at 04:35, Jan Hubicka wrote:
>
> > Hello,
> > > While going through the patch and simple-object.c I understood that the
> > > file simple-o
Hello,
> While going through the patch and simple-object.c I understood that the
> file simple-object.c is used to handle the object file format. However,
> this file does not contain all the architecture information required for
> LTO object files, so the workaround used in the patch is to read th
Hi,
>
> It seems to me that the most correct fix is to add to
> walk_polymorphic_call_targets a check that the obtained possible target
> is still referenced_from_vtable_p() - because the alias that was
> originally a virtual function is referenced from a vtable that at this
> point is also known
Hello,
> Hi! I've been interested in compiler development for a while, and would love
> to
> work with any of you as part of GSoC, or even just as a side-project on my
> own.
>
> I'm an 18 year-old student going into university next year with a passion for
> all
> things open source and low lev
ERS b/MAINTAINERS
> index 18edc86df67..a61d3ae06df 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -230,7 +230,6 @@ docstring relicensing Gerald Pfeifer
>
> docstring relicensingJoseph Myers
>
> predict.def Jan Hubicka
Hello,
> Hello,
>
> We are pleased to invite you all to the next GNU Tools Cauldron,
> taking place in Paris on September 16-18, 2022. We are looking forward
> to meet you again after three years!
>
> As for the previous instances, we have setup a wiki page for
> details:
>
> https://gcc.g
s and developers, would you be
> interested to take on the responsibility of maintaining the
> AutoFDO-specific portions of the code, with guidance and mentorship
> from other GCC maintainers, especially the ones responsible for gcov
> and PDO?
I missed the patches (it would help t
> On Sat, May 14, 2022 at 7:03 PM Jan Hubicka via Gcc wrote:
> >
> > Hello,
> >
> > We are pleased to invite you all to the next GNU Tools Cauldron,
> > taking place in Paris on September 16-18, 2022. We are looking forward
> > to meet you again after three
Hello,
We are pleased to invite you all to the next GNU Tools Cauldron,
taking place in Paris on September 16-18, 2022. We are looking forward
to meet you again after three years!
As for the previous instances, we have setup a wiki page for
details:
https://gcc.gnu.org/wiki/cauldron2022
Hi,
>
>
> > On 08-Apr-2022, at 6:32 PM, Jan Hubicka wrote:
> >
> > Ankur,
> >> I was browsing the list of submitted GSoC projects this year and the
> >> project regarding bypassing assembler when generating LTO object files
> >> caught my ey
Ankur,
> I was browsing the list of submitted GSoC projects this year and the
> project regarding bypassing assembler when generating LTO object files
> caught my eye.
I apologize for late reply. I would be very happy to mentor this
project.
>
> I already have a gcc built from source (sync-ed wit
> Hi,
>
> I would like to use ipa_ref in the PASS_LIST all_late_ipa_passes to query
> the statement (ref->stmt) of where a global variable is used. However, I am
> having some problems achieving this.
>
> What I do is:
>
> 1. Check that ipa_ref->referring has a body and is not inlined.
> 2. get_
> Hi,
> In function ref_maybe_used_by_call_p_1, there is below code snippet
> /* The following builtins do not read from memory. */
> case BUILT_IN_FREE:
> ...
>return false;
>
> I am confused because free function does read from (and even write to)
> memory
>
> I can confirm that zero-initializing node_is_self_scc prevents the
> uninitialised use warnings in incorporate_penalties (ipa-cp.c:3282)
Great, I will commit the patch. But I also wonder if there are any
remaining unitialized warnings in ipa code?
Honza
>
> Thanks,
> Zdenek
>
>
> >
> > diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
> > index 42842d9466a..1d0c115465c 100644
> > --- a/gcc/ipa-prop.h
> > +++ b/gcc/ipa-prop.h
> > @@ -623,8 +623,8 @@ ipa_node_params::ipa_node_params ()
> > : descriptors (NULL), lattices (NULL), ipcp_orig_node (NULL),
> >known_csts (vNULL),
> ==5404== Conditional jump or move depends on uninitialised value(s)
> ==5404== at 0x25DAAD7: incorporate_penalties (ipa-cp.c:3282)
> ==5404== by 0x25DAAD7: good_cloning_opportunity_p(cgraph_node*, sreal,
> sreal, profile_count, int) (ipa-cp.c:3340)
I looked at this one (since it is in code
> Hello,
>
> I have a SIMPLE_IPA_PASS that parses the program multiple times. As it
> parses gimple, it builds a data structure with the information
> collected that will provide some invariants to future iterations over
> the program.
>
> I was looking into adding a new feature that would take a
> Good hint. I added hash based on object file name (I don't want to handle
> proper string escaping) and -frandom-seed.
>
> What do you think about the patch?
Sorry for taking so long - I remember I was sending reply earlier but it
seems I only wrote it and never sent.
> Thanks,
> Martin
> From
> On Thu, May 20, 2021 at 3:16 PM Richard Biener
> wrote:
> >
> > On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote:
> > >
> > > On 5/20/21 2:54 PM, Richard Biener wrote:
> > > > So why did you go from applying this per-file to multiple files?
> > >
> > > When I did per-file for {gimple,generic}
>
> > With my tests, AutoFDO could achieve almost half of the effect of
> > instrumentation FDO on real applications such as MySQL 8.0.20 .
>
> Likely this could be improved with some of the missing changes. Apparently
> discriminator support is worth quite a bit especially on dense C++ code
> ba
gt; > > Thoughts?
> > > >> > > > > Martin
> > > >> > > > >
> > > >> > > > > >
> > > >> > > > > > Having the tool third-party makes keeping the whole chain
> > > >> working
>
> On Fri, Apr 23, 2021 at 10:27 AM Xinliang David Li
> wrote:
>
> >
> >
> > On Fri, Apr 23, 2021 at 10:16 AM Jan Hubicka wrote:
> >
> >> >
> >> > It uses create_llvm_prof tool which is in the same git repo. The data
> >> >
third-party makes keeping the whole chain working more
> > difficult.
> >
> > Richard.
> >
> >> Thanks,
> >>
> >> David
> >>
> >> On Thu, Apr 22, 2021 at 3:29 PM Jan Hubicka wrote:
> >>
> >>>> On 4
gt; > > difficult.
> > > > >
> > > > > Richard.
> > > > >
> > > > >> Thanks,
> > > > >>
> > > > >> David
> > > > >>
> > > > >> On Thu, Apr 22, 2021 at 3:29 PM J
ible format and how easy would be to keep this alive.
David, how does perf->LLVM path work these days?
Honza
>
> David
>
> >
> > Thoughts?
> > Martin
> >
> > >
> > > Having the tool third-party makes keeping the whole chain working more
> > > diffi
> On 4/22/21 9:58 PM, Eugene Rozenfeld via Gcc wrote:
> > GCC documentation for AutoFDO points to create_gcov tool that converts
> > perf.data file into gcov format that can be consumed by gcc with
> > -fauto-profile (https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html,
> > https://gcc.gnu.
> The reason this is not done is because the summaries (constraints)
> are huge, the solutions are even larger and the PTA solver doesn't
> scale to large units (so the LTRANS splitting makes it actually usable
> in the first place).
I did not spent that much time working on PTA as Richard, but it
> gcc does not reduce to call result if called function is not static in
> -O2 (will do with -O2)
> clang and msvc does it also in -O2 regardless of the function beeing
> static or not
>
> can someone explain to me why the -O2 optimizer is not able(allowed) to
> reduce this small sample the same w
> On 11/16/20 1:44 PM, Jan Hubicka wrote:
> > Martin, we collected very many warnings when building with
> > configure --with-build-config=bootstrap-lto.mk
> > This patch fixes some of them, but there are many others, can you take a
> > look?
>
> Hello.
>
>
> >
> > Richi, I think we can add "safe" parameter to gimple_call_arg_flags and
> > bypass this logic when we use it for warnings only (having body that
> > does not use the value is quite strong hint that it is unused by the
> > function).
>
> Eh, please not.
OK, I do not care that much as long
> On Nov 15 2020, Jan Hubicka wrote:
>
> >> See PR97840.
> > Thanks,
> > this is a false positive where we fail to discover that pointed-to type
> > is empty on non-x86_64 targets. This is triggered by better alias
> > analysis caused by non-escape discover
> See PR97840.
Thanks,
this is a false positive where we fail to discover that pointed-to type
is empty on non-x86_64 targets. This is triggered by better alias
analysis caused by non-escape discovery.
While this is not a full fix (I hope someone with more experience on
C++ types and warnings wil
> On Fri, Nov 13, 2020 at 12:07 AM Richard Biener wrote:
> >
> > On Tue, 10 Nov 2020, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updaed patch.
> > >
> > > Honza
> > >
> > > Bootstrapped/regtested x86_64-linux, OK (afte
> Hi Jan,
>
> >> I'm seeing the same on both i386-pc-solaris2.11 and
> >> sparc-sun-solaris2.11, so I don't think there are special configure
> >> flags involved.
> >
> > When I configure with ../configure --enable-languages=go my build
> > eventually finishes fine on curren trunk:
> [...]
> > On
> Hi Jan,
>
> >> This breaks bootstrap with go.
> >>
> >> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> >> expand_message(const char*, va_list)':
> >> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may
> >> be used uninitialized [-Werror=maybe-uninitialized]
> This breaks bootstrap with go.
>
> ../../gcc/go/gofrontend/go-diagnostics.cc: In function 'std::string
> expand_message(const char*, va_list)':
> ../../gcc/go/gofrontend/go-diagnostics.cc:110:61: error: '' may be
> used uninitialized [-Werror=maybe-uninitialized]
> 110 |
Hi,
here is updaed patch.
Honza
Bootstrapped/regtested x86_64-linux, OK (after the fnspec fixes)?
2020-11-10 Jan Hubicka
* gimple.c: Include ipa-modref-tree.h and ipa-modref.h.
(gimple_call_arg_flags): Use modref to determine flags.
* ipa-modref.c: Include gimple
> > + tree callee = gimple_call_fndecl (stmt);
> > + if (callee)
> > +{
> > + cgraph_node *node = cgraph_node::get (callee);
> > + modref_summary *summary = node ? get_modref_function_summary (node)
> > + : NULL;
> > +
> > + if (summary && summary->arg
> > Bootstrapped/regtested x86_64-linux, OK?
> > (I will analyze more the t2.c failure)
>
> I have found independent reproducer that is now in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
... and with Jakub's fix the testcase works now.
Honza
>
> Honza
> Bootstrapped/regtested x86_64-linux, OK?
> (I will analyze more the t2.c failure)
I have found independent reproducer that is now in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97775
Honza
>
> Alias oracle query stats:
> refs_may_alias_p: 65808750 disambiguations, 75664890 queries
> ref_maybe_used_by_call_p: 153485 disambiguations, 66711204 queries
> call_may_clobber_ref_p: 22816 disambiguations, 28889 queries
> nonoverlapping_component_refs_p: 0 disambiguations, 36846 queri
that it is not independent
change (but both build was from almost same checkout).
Bootstrapped/regtested x86_64-linux, OK?
(I will analyze more the t2.c failure)
Honza
gcc/ChangeLog:
2020-11-10 Jan Hubicka
* gimple.c: Include ipa-modref-tree.h and ipa-modref.h
I am running full bootstrap/regtest.
On tramp3d the effect is not great, but it does something.
PTA query stats:
pt_solution_includes: 397269 disambiguations, 606922 queries
pt_solutions_intersect: 138302 disambiguations, 416884 queries
to
PTA query stats:
pt_solution_includes: 401540 d
> > But it also means that some of our FNSPECs are wrong now. I wonder if we
> > can
> > split this porperty to two different flags like EAF_NOEASCAPE and
> > EAF_INDIRECT_NOESCAPE?
>
> Note that EAF_NOESCAPE allows "escaping" to the return value (see
> handle_rhs_call). I guess for simplicity
Hi,
I implemented simple propagation of EAF arguments for ipa-modref (that is not
hard to do). My main aim was to detect cases where THIS parameter does not
escape but is used to read/write pointed to memory. This is meant to
avoid poor code produced when we i.e. offline destructors on cold path.
ay be some issues as this path is untested and
i.e ipa-sra/ipa-prop does quite difficult transformations these days.
What happens?
Honza
>
> Richard.
>
> > Am I missing something?
> >
> > Gary
> >
> > From: Jan Hubicka
> > S
> > On Tue, Oct 20, 2020 at 1:02 PM Martin Jambor wrote:
> > >
> > > Hi,
> > >
> > > On Tue, Oct 20 2020, Richard Biener wrote:
> > > > On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock
> > > > wrote:
> > > >>
> > > >> Richard,
> > > >>
> > > >> I guess that will work for me. However, since it
> > > >
> On Tue, Oct 20, 2020 at 1:02 PM Martin Jambor wrote:
> >
> > Hi,
> >
> > On Tue, Oct 20 2020, Richard Biener wrote:
> > > On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock
> > > wrote:
> > >>
> > >> Richard,
> > >>
> > >> I guess that will work for me. However, since it
> > >> was decided to remove
> > So, IIUC, you're trying to replace the old
> > refs/users/hubicka/heads/honza-gcc-benchmark-branch
> > with whatever is on master at this moment, is that correct
> > (that would wipe whatever changes you've made in your old
> > branch)?
> >
> > For instance, currently master is pointing to com
> On Tue, Sep 29, 2020 at 07:16:45PM +0200, Jan Hubicka wrote:
> > > On Tue, 29 Sep 2020, Joel Brobecker wrote:
> > >
> > > > > > That's correct. The commit-extra-checker is called using the same
> > > > > > list
> > > >
> On Tue, 29 Sep 2020, Joel Brobecker wrote:
>
> > > > That's correct. The commit-extra-checker is called using the same list
> > > > of "added commits" as the other checks implemented in the hooks, and
> > > > that list excludes all commits accessible from existing references
> > > > in the repos
> On Tue, Sep 29, 2020 at 9:17 AM Jan Hubicka wrote:
> >
> > Hello,
> > I am trying to update me/honza-gcc-benchmark-branch to current trunk
> > which I do by deleting it, recreating locally and pushing out.
> >
> > The problem is that the push fails w
Hello,
I am trying to update me/honza-gcc-benchmark-branch to current trunk
which I do by deleting it, recreating locally and pushing out.
The problem is that the push fails witih:
remote: *** The following commit was rejected by your
hooks.commit-extra-checker script (status: 1)
remote: *** com
> > I guess before investigating the current state in detail
> > it might be worth exploring Honzas wish of sharing
> > the actual partitioning code between LTO and -fparallel-jobs.
> >
> > Note that larger objects take a bigger hit from the GC COW
> > issue so at some point that becomes dominant
> Thanks for the suggestions.
> Is it possible to modify assembly files emitted after ltrans phase ?
> IIUC, the linker invokes lto1 twice, for wpa and ltrans,and then links
> the obtained object files which doesn't make it possible to hand edit
> assembly files post ltrans ?
> In particular, I wan
> On Fri, Aug 28, 2020 at 10:32 PM Giuliano Belinassi
> wrote:
> >
> > Hi,
> >
> > This is the final report of the "Automatic Parallel Compilation
> > Viability" project. Please notice that this report is pretty
> > similar to the delivered from the 2nd evaluation, as this phase
> > consisted of
> Hi,
>
> is there a way to find out that a function is a clone of another function
> after materialization? I believe that `clone_of_p` only works before
> materialization. I tried and no clones were detected.
After materialization function becomes a normal function, but there is
former_clone_of
> Hey.
>
> Some of you may know Honza's images about CPU utilization and memory usage
> when using LTO [1]. Last week I played with Chromium and Firefox and I wanted
> to visualize their utilization. That's why I came up with a new script [2].
>
> You can easily wrap a command and the script gene
as an issue, and that your answers has provided some
> clarification,
> what is about the STEP 2? As far as I know, it is not supported, it is?
>
> Frédéric Recoules
>
>
> - Mail original -
> De: "Jan Hubicka"
> À: "Richard Biener"
> Cc
> >I was pretty disappointed to see that even if the compiler knows we are
> >calling f_add, it doesn't inline the call (it ends up with "call
> >f_add").
>
> It's probably because we know it's only called once and thus not performance
> relevant. Try put it into a loop.
I think it is because d
> Hello,
Hello,
>
> I am trying to find out the arguments of functions which are undefined
> during LTO.
>
> Basically:
>
> gcc_assert(in_lto_p && !cnode->definition)
> // Do we have arguments?
> gcc_assert(DECL_ARGUMENTS(cnode->decl)) // fails
> // No, we don't.
>
> As I understand it, functio
ng a region based function
> splitting could improve ipa-split.
>
> -Aditya
>
>
> --
> From: Martin Liška
> Sent: Tuesday, March 3, 2020 2:47 AM
> To: Aditya K ; gcc@gcc.gnu.org
> Cc: Jan Hubicka
> Subject: Re: GSoC topic: Implement hot cold splitting at
p; does something useful
seems like good first step (which is hard enough at its own).
So I would suggest to look at -flto-partition=none first and keep in
mind that eventually we will want a solution that plays well with
partitioning.
Honza
>
> Richard.
>
> > Gary
> > ____
> There doesn't seem to be a way to compare types at LTO time. The functions
> same_type_p and comptypes are front end only if I'm not totally confused
> (which is quite possible) and type_hash_eq doesn't seem to apply for
> structure types. Please, any advice would be welcome.
At LTO time it is b
times (such as ones
> > initialized in initialization functions).
> [ ... ]
> Just a note, I suspect most of the development community is currently
> focused on stage3 bugfixing rather than new code development. So
> replies may be limited.
>
> Jan Hubicka is probably the
>
> > On 27 Jun 2019, at 19:21, Jan Hubicka wrote:
> >
> >>
> >> It's useful on targets without COMDAT support. Are there any such
> >> that we care about at this point?
> >>
> >> If the problem is the combination with LTO
>
> It's useful on targets without COMDAT support. Are there any such
> that we care about at this point?
>
> If the problem is the combination with LTO, why not just prohibit that?
The problem is that at the collect2 time we want to decide whether to
hold stderr/stdout of the linker. The issue
> Hello.
> I have already sent a patch for expanding roundeven for i386 with
> relevant doubts. I also was regression testing with
> make -k check
> after successful bootstrap build with reverting my patches. Turns out
> do-check fails without any patches applied, Is it ok to do anyways for
> appli
> On 6/21/19 2:34 PM, Richard Biener wrote:
> > On Fri, Jun 21, 2019 at 12:20 PM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> The patch is about a new ELF section that will contain information
> >> about LTO version. And for the future, used compression will be stored
> >> here. The patch removes s
> > >> I should have been clearer about Darwin:
> > >>
> > >> collect2 is required because it wraps the calling of lto-wrapper and ld.
> > >>
> > >> FWIW Darwin also passes all the “-frepo” testcases, however, I’m not
> > >> aware of anyone actually
> > >> using case #2 from Jonathan’s post.
> > >
> On 6/20/19 12:58 PM, Thomas Koenig wrote:
> > Am 20.06.19 um 11:07 schrieb Martin Liška:
> >> On the contrary, decompression
> >> of zstd with zlib will end with:
> >> lto1: internal compiler error: compressed stream: data error
> >
> > Sogenerating object files on one system and trying to read
>
> At least allow it to be built as part of the normal build like GMP,
> etc. are done.
> And include it in downloading using contrib/download_prerequisites
> like the libraries are done.
Anoying detail is that zstd builds with cmake, not autotools
Honza
>
> Thanks,
> Andrew Pinski
>
> >
> >
> Hi,
>
> On Mon, 15 Apr 2019, Martin Liška wrote:
>
> > There's a similar comparison that I did for the official openSUSE gcc
> > packages. gcc8 is built with PGO, while the gcc9 package is built in 2
> > different configurations: PGO, LTO, PGO+LTO (LTO used for FE in stage4,
> > for generato
> On Wed, Jan 9, 2019 at 12:48 PM Richard Biener
> wrote:
> >
> > On Wed, Jan 9, 2019 at 10:46 AM Joern Wolfgang Rennecke
> > wrote:
> > >
> > > We've been running builds/regression tests for GCC 8.2 configured with
> > > --enable-checking=all, and have observed some failures related to
> > > gar
> On Mon, Jan 07, 2019 at 09:29:09AM +0100, Richard Biener wrote:
> > On Sun, 6 Jan 2019, Jan Hubicka wrote:
> > > Even though it is late in release cycle I wonder if we can do that for
> > > GCC 9? Performance of vectorization is very architecture specific, I
&
> > Note that I benchmarked -ftree-slp-vectorize separately before and
> > results was hit/miss, so perhaps enabling only -ftree-vectorize would
> > give better compile time tradeoffs. I was worried of partial memory
> > stalls, but I will benchmark it and also benchmark difference between
> > cost
Hello,
while running benchmarks for inliner tuning I also run benchmarks
comparing -O2 and -O2 -ftree-vectorize -ftree-slp-vectorize using Martin
Liska's LNT setup (https://lnt.opensuse.org/). The results are
summarized below but you can also see also colorful table produced
by Martin's LNT magic
> Honza,
>
> At the Cauldron meeting last week I mentioned that I wasn't able to compile
> our "small" weather forecasting program with LTO.
>
> In the mean time I have read some bug reports with "multiple prevailing ..."
> errors, which made me try linking with the 'gold' linker - that worked.
>
>
> Hi,
>
> I'm in the process of changing the vectorizer to consider all
> vector sizes as advertised by targetm.autovectorize_vector_sizes
> and to decide which one to use based on its cost model.
>
> I expect that to make sense for example when choosing between
> AVX128 and AVX256 since the l
> On 05/30/2018 12:27 PM, Gerald Pfeifer wrote:
> >On Wed, 30 May 2018, Martin Sebor wrote:
> >>I think your r260956 is missing the following hunk:
> >
> >If this fixes the bootstrap for you (also ran into this myself
> >just now), can you please go ahead and commit?
> >
> >We can always sort out t
> On 03/21/2018 10:26 AM, Richard Biener wrote:
> >On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška wrote:
> >>Hi.
> >>
> >>I did similar stats for postgresql server, more precisely for pgbench:
> >>pgbench -s100 & 10 runs of pgbench -t1 -v
> >
> >Without looking at the benchmark probably only be
Hello,
I have also re-done most of my firefox testing similar to ones I published at
http://hubicka.blogspot.cz/2014/04/linktime-optimization-in-gcc-2-firefox.html
(thanks to Martin Liska who got LTO builds to work again)
I am attaching statistics on binary sizes. Interesting is that for firefox
> On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka wrote:
> >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni
> >> wrote:
> >> > Hi,
> >> >
> >> > Thank you Richard and Honza for the suggestions. If I understand
> >> > c
e
> for the cgraph in the file, etc.
>
> Basically while there's a lot of dumping infrastructure in GCC
> it may not always fit the needs of a LTO IL dumping tool 1:1
> and may need refactoring enhancement.
>
> Richard.
>
> >
> > Thanks,
> >
> > Hrishikes
> On Tue, Mar 6, 2018 at 11:12 AM, Martin Liška wrote:
> > Hello.
> >
> > Many significant changes has landed in mainline and will be released as GCC
> > 8.1.
> > I decided to use various GCC configs we have and test how there
> > configuration differ
> > in size and also binary size.
> >
> > Th
1 - 100 of 681 matches
Mail list logo
