Re: AutoFDO profile toolchain is open-sourced

Yes, it will. But it's not well tuned at all. I will start tuning it if I have free cycles. It would be great if opensource community can also contribute to this tuning effort. If you could outline portions of code which needs tuning, rewriting, that will help get started in this

Passsing unfinished types to gen_type_die_with_usage

Hello, as I mentioned yesterday on IRC adding a check that only complete types have TYPE_BINFO defined triggers on type: record_type 0x76d24d20 __is_integer type_5 type_6 VOID align 8 symtab 0 alias set -1 canonical type 0x76d24d20 fields const_decl 0x74a89930 __value

Re: g++keeps unused objects with virtual functions

which shows how the global objects initialization keeps things live. Early optimization turns it into (static initializers for t.C) () { bb 2: NotUsedObject._vptr.CObject = MEM[(void *)_ZTV7CObject + 16B]; return; } but we don't have any pass removing stores to globals never

Re: g++keeps unused objects with virtual functions

which shows how the global objects initialization keeps things live. Early optimization turns it into (static initializers for t.C) () { bb 2: NotUsedObject._vptr.CObject = MEM[(void *)_ZTV7CObject + 16B]; return; } but we don't have any pass removing stores to

Re: AutoFDO profile toolchain is open-sourced

On Tue, Apr 7, 2015 at 9:45 AM, Ilya Palachev i.palac...@samsung.com wrote: In the mentioned README file it is said that In order to collect this profile, you will need to have an Intel CPU that have last branch record (LBR) support. Is this information obsolete? Chrome Canary builds use

Re: AutoFDO profile toolchain is open-sourced

LBR is used for both cfg edge profiling and indirect call Target value profiling. I see, that makes sense ;) I guess if we want to support profile collection on targets w/o this feature we could still use one of the algorithms that try to guess edge profile from BB profile. Honza

Re: lto bootstrap fails.

On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in

Re: debug-early branch merged into mainline

On 06/06/2015 03:33 PM, Jan Hubicka wrote: Aldy, also at PPC64le LTO bootstrap (at gcc112) dies with: ^ 0x104ae8f7 check_die ../../gcc/dwarf2out.c:5715 Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO path does not do the early DIE dance. Since check_die

Re: debug-early branch merged into mainline

On 06/06/2015 03:33 PM, Jan Hubicka wrote: Aldy, also at PPC64le LTO bootstrap (at gcc112) dies with: ^ 0x104ae8f7 check_die ../../gcc/dwarf2out.c:5715 Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO path does not do the early DIE dance. Since

Re: debug-early branch merged into mainline

Aldy, also at PPC64le LTO bootstrap (at gcc112) dies with: ^ 0x104ae8f7 check_die ../../gcc/dwarf2out.c:5715 0x104e4e1b dwarf2out_decl ../../gcc/dwarf2out.c:21886 0x104d8a87 dwarf2out_abstract_function ../../gcc/dwarf2out.c:18457 0x104dd3e7 gen_inlined_subroutine_die

GNU Tools Cauldron 2015 - Call for Participation

Hello, A reminder about this year's Cauldron (http://gcc.gnu.org/wiki/cauldron2015). The webpage was just updated with a list of accepted talks and BoFs as well as a brief review of the schedule to let you plan your travel. With 19 of very relevant talks and 10 BoFs we will have a busy schedule.

Re: getrlimit compatibility issues

> @@ -811,5 +806,9 @@ lto_symtab_prevailing_decl (tree decl) >if (!ret) > return decl; > > + /* Do not replace a non-builtin with a builtin. */ > + if (is_builtin_fn (ret->decl)) > +return decl; > + Yep, this looks like a resonable direction. It will break the one declaration

Re: getrlimit compatibility issues

> > Yep, this looks like a resonable direction. It will break the one > > declaration > > rule in a more wild sense than current frontends does so, because if a > > builtin > > win as a prevailing declaration, we end up with no merging at all. > > I wonder if we don't want to always prevail to

Re: getrlimit compatibility issues

> On Tue, 1 Sep 2015, Jan Hubicka wrote: > > > > > Yep, this looks like a resonable direction. It will break the one > > > > declaration > > > > rule in a more wild sense than current frontends does so, because if a > > > > buil

Re: ipa vrp implementation in gcc

> On Mon, Jan 11, 2016 at 1:38 AM, Kugan > <kugan.vivekanandara...@linaro.org> wrote: > > Hi All, > > > > I am looking at implementing a ipa vrp pass. Jan Hubicka also talks > > about this in 2013 GNU Cauldron as one of the optimization he would like > >

Re: help with PR69133

> On Mon, Jan 18, 2016 at 10:28 AM, Prathamesh Kulkarni > wrote: > > On 17 January 2016 at 14:56, Prathamesh Kulkarni > > wrote: > >> Hi, > >> I was having a look at PR69133. > >> It appears that with -flto-partition=none, > >>

Re: ipa vrp implementation in gcc

> On Mon, Jan 18, 2016 at 12:00 AM, Kugan > wrote: > > Hi, > > > >> Another potential use of value ranges is the profile estimation. > >> http://www.lighterra.com/papers/valuerangeprop/Patterson1995-ValueRangeProp.pdf > >> It seems to me that we may want to have

Re: r235766 incomplete?

+ val = ipa_find_agg_cst_for_param (agg, > > known_vals[c->operand_num], > > + c->offset, c > > ->by_ref); > > I saw this too (with r235766). I believe it's fixed by r235770 and > r235771:

Re: How to check if two symbols are from same source unit during WPA ?

> On Thu, 14 Apr 2016, Ramana Radhakrishnan wrote: > > > > > > > > > What happens in practice? GCC doesn't put functions in random > > > partitions. > > > > > > > The data goes into a separate partition AFAIU - it means that all data > > accesses are as though they are extern references

Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

> Hi! > > So here is a proof of concept of an attribute that disables inlining, > cloning, ICF, IPA VRP, IPA bit CCP, IPA RA, pure/const/throw discovery. > Does it look reasonable? Anything still missing? I think you also want to disable optimizations we do about local functions (stack

Re: Worse code after bbro?

> On 01/04/2017 03:46 AM, Segher Boessenkool wrote: > >On Wed, Jan 04, 2017 at 10:05:49AM +0100, Richard Biener wrote: > >>>The code size is identical, but the trunk version executes one more > >>>instruction everytime the loop runs (explicit jump to .L5 with trunk vs > >>>fallthrough with 4.8) -

Re: Question about inlining and strict_aliasing

> Hello. > > I've been working on a patch that would cope with target and optimization > (read PerFunction) > in a proper way. I came to following test-case (slightly modified > ./gcc/testsuite/gcc.c-torture/execute/alias-1.c): > > int val; > > int *ptr = > float *ptr2 = > > static >

GNU Tools Cauldron 2017, Prague, September 8-10

Hi, we are very pleased to invite you all the GNU Tools Cauldron on 8-10 September 2017. This year we will meet again in Prague, at Charles University. Details are here: https://gcc.gnu.org/wiki/cauldron2017 As usual, please register (capacity is limited), send abstracts and ask

GNU Tools Cauldron 2017, September 8-10, 2017

Hello, I would like to remind you of the upcoming GNU Tools Cauldron meeting in Prague September 8-10. https://gcc.gnu.org/wiki/cauldron2017 (in 5 weeks!) At the present we still have 83 registered participants and the room capacity is bit over 100 seats. If you want to participate, please

Re: .bad_compare in bootstrap of head

Hi, I found the problem. It was pretty obvious - we compute sum of times twice. Once when computing statement sizes and second time by summing the summaries. because sreal is not distributive, it leads to different results. I have comitted the following patch. Incrementally I will drop the code

Re: .bad_compare in bootstrap of head

> > On 05/04/2017 08:31 AM, Jeff Law wrote: > > >On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote: > > >>Fedora 26 x86_64 > > >>r247595 > > >> > > >>~/src/gcc_current/configure --prefix=/usr/local/gcc_current > > >>--enable-static --enable-checking=no --enable-languages=c,c++,lto > >

Re: .bad_compare in bootstrap of head

> On 05/04/2017 08:31 AM, Jeff Law wrote: > >On 05/04/2017 07:26 AM, Дмитрий Дьяченко wrote: > >>Fedora 26 x86_64 > >>r247595 > >> > >>~/src/gcc_current/configure --prefix=/usr/local/gcc_current > >>--enable-static --enable-checking=no --enable-languages=c,c++,lto > >>--enable-plugin

Re: .bad_compare in bootstrap of head

> > I wonder how that patch can cause mismatches. Does it reproduce on one of > > compile farm machines (my x86-64 bootstrap works fine so does ia64 on > > terbium > > after fixing the gcc 4.1 issue yeterday). > > It would be great to have -fdump-ipa-inline-details dumps of the mismatching > >

Re: RFC: Improving GCC8 default option settings

> On Wed, Sep 13, 2017 at 3:21 AM, Michael Clark wrote: > > > >> On 13 Sep 2017, at 1:15 PM, Michael Clark wrote: > >> > >> - https://rv8.io/bench#optimisation > >> - https://rv8.io/bench#executable-file-sizes > >> > >> -O2 is 98% perf of -O3 on

Re: RFC: Improving GCC8 default option settings

> >I don't see static profile prediction to be very useful here to find > >"really > >hot code" - neither in current implementation or future. The problem of > >-O2 is that we kind of know that only 10% of code somewhere matters for > >performance but we have no way to reliably identify it. > >

Re: RFC: Improving GCC8 default option settings

> On Wed, Sep 13, 2017 at 3:46 PM, Jakub Jelinek wrote: > > On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote: > >> On its own -O3 doesn't add much (some loop opts and slightly more > >> aggressive inlining/unrolling), so whatever it does we > >> should consider

Re: GNU Tools Cauldron 2017: OMP (Offloading and Multi Processing) BoF

> Hi! > > As Honza told me recently, it has been proposed by Martin -- I don't know > which one ;-) -- and certainly makes sense, to have another OMP > (Offloading and Multi Processing) BoF at the GNU Tools Cauldron 2017, > which is currently scheduled for Saturday, 11:00 to 11:45. That is, a >

Slides from GNU Tools Cauldron

Hello, all but one videos from this year Cauldron has been edited and are now linked from https://gcc.gnu.org/wiki/cauldron2017 (plugins BoF will appear till end of week). I would also like to update the page with links to slides. If someone beats me on this and adds some or all of them as

Re: Vectorizer size preferences (-mprefer-* on x86)

> > 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

Re: bootstrap failure due to declaration mismatch in r260956

> 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

Re: Problems in IPA passes

Dne 2017-10-28 09:28, Jeff Law napsal: Jan, What's the purpose behind calling vrp_meet and extract_range_from_unary_expr from within the IPA passes? AFAICT that is not safe to do. Various paths through those routines will access static objects within tree-vrp.c which may not be initialized

Re: Resolving LTO symbols for static library boundary

Dne 2018-02-05 18:44, Richard Biener napsal: On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen wrote: Hello GCC In trying to make it possible to use LTO for distro-builds of Qt, I have again hit the problem of static libraries. In Qt in general we for LTO

Re: How big (and fast) is going to be GCC 8?

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

Re: GSOC 2018 - Textual LTO dump tool project

> On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka <hubi...@ucw.cz> wrote: > >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni > >> <hrishikeshpa...@gmail.com> wrote: > >> > Hi, > >> > > >> > Thank you Richard and Honza for

Re: GSOC 2018 - Textual LTO dump tool project

cement. I would agree here - dumping pass summaries would be nice but we already have that more or less. All IPA passes dump their summary into beggining of their dump file and I find that relatively sufficient to deal with mostly because summaries are quite simple. It is much harder to deal with

Re: How big (and fast) is going to be GCC 8?

> 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

Re: GSOC 2018 - Textual LTO dump tool project

t; 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, > > > > Hrishikesh

Re: How can compiler speed-up postgresql database?

> 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

Re: GSOC 2018 - Textual LTO dump tool project

Hello, > On Fri, Mar 2, 2018 at 10:24 AM, Hrishikesh Kulkarni > wrote: > > Hello everyone, > > > > > > Thanks for your suggestions and engaging response. > > > > Based on the feedback I think that the scope of this project comprises of > > following three indicative

Enabling vectorization at -O2 for x86 generic, core and zen tuning

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

Re: Enabling vectorization at -O2 for x86 generic, core and zen tuning

> > 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 > >

Re: Enabling vectorization at -O2 for x86 generic, core and zen tuning

> 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 &

Re: Garbage collection bugs

> 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 > > >

Re: Large Fortran program succesfully LTO'd.

> 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.

Re: GCC 8 vs. GCC 9 speed and size comparison

> 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

Re: Expanding roundeven (Was: Re: About GSOC.)

> 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 >

Re: [RFC] zstd as a compression algorithm for LTO

> > 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 > > > > >

Re: [RFC] zstd as a compression algorithm for LTO

> 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

Re: [PATCH] Add .gnu.lto_.meta section.

> 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

Re: Dropping support of repo files (tlink)

> > >> 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. > >

Re: [PATCH] Deprecate -frepo option.

> > > 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 combinatio

Re: [PATCH] Deprecate -frepo option.

> > 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

Re: Questions about IPA/clones and new LTO pass

mes (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 best

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

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 GIMPL

Re: Comparing types at LTO time

> 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

Re: [EXT] Re: Option processing question

mething 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 > > ______

Re: Question about undefined functions' parameters during LTO

> 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,

Re: Thought on inlining indirect function calls

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: &qu

Re: Thought on inlining indirect function calls

> >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

Re: LTO slows down calculix by more than 10% on aarch64

> 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

Re: [GSoC] Automatic Parallel Compilation Viability -- Final Report

> 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

Re: [GSoC] Automatic Parallel Compilation Viability -- Final Report

> > 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

Re: Where did my function go?

> 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

Re: Where did my function go?

> > 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 > > >

Re: Git rejecting branch merge

> 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

Re: Git rejecting branch merge

> 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

Re: Git rejecting branch merge

> 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 > > > >

Re: Git rejecting branch merge

> > 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

Git rejecting branch merge

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: ***

Re: GCC usage script

> 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

Re: gcc does not reduce the function call to the result if called function is not static when using -O2, only with -O3, clang and msvc do the optimization also with -O2

> 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

Re: Detect EAF flags in ipa-modref

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

Definition of EAF_NOESCAPE and fnspec strings

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

Re: Detect EAF flags in ipa-modref

> > 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

Re: Detect EAF flags in ipa-modref

> 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

Re: Detect EAF flags in ipa-modref

> > 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

Re: Detect EAF flags in ipa-modref

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

Re: Detect EAF flags in ipa-modref

> > + 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 &&

Re: Detect EAF flags in ipa-modref

> > > > 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

Re: Detect EAF flags in ipa-modref

> 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

Re: Detect EAF flags in ipa-modref

> 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. > >

Re: Definition of EAF_NOESCAPE and fnspec strings

> > 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

Detect EAF flags in ipa-modref

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 disambiguations, 609093 queries pt_solu

Re: Detect EAF flags in ipa-modref

> 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 |

Re: Detect EAF flags in ipa-modref

> 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-

Re: Detect EAF flags in ipa-modref

> 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

Re: Detect EAF flags in ipa-modref

> 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

Re: Detect EAF flags in ipa-modref

> 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

Re: Where did my function go?

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 > > Sent: Tuesd

Re: State of AutoFDO in GCC

> > > 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 >

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

> 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

Re: State of AutoFDO in GCC

t 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 > > > difficult. >

Re: State of AutoFDO in GCC

; > > > difficult. > > > > > > > > > > Richard. > > > > > > > > > >> Thanks, > > > > >> > > > > >> David > > > > >> > > > > >> On Thu, Apr 22, 2021 at 3:29 PM J

Re: State of AutoFDO in GCC

e chain working more > > difficult. > > > > Richard. > > > >> Thanks, > >> > >> David > >> > >> On Thu, Apr 22, 2021 at 3:29 PM Jan Hubicka wrote: > >> > >>>> On 4/22/21 9:58 PM, Eugene Rozenfeld vi

Re: State of AutoFDO in GCC

> 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 > >> >

<    1   2   3   4   5   6   7   8   9   10   >