> The C constraint on x86 is defined, in both the doc and the comments, as
> "constant that can be easily constructed in SSE register without loading
> from memory". Currently the only one handled is 0, but there is at
> least
> one more, all 1 bits, which is constructed by
>pcmpeqd %xmm, %
> On Fri, Sep 30, 2005 at 04:31:59PM -0700, Dale Johannesen wrote:
> > No, there isn't, but it might be a smaller change to add a new
> > constraint
> > having constraints tied to specific constants is pretty ugly, and so is
> > having (if (constant value==0)) in a lot of patterns..,,
>
> Tha
> Hi Jan,
>
> I think fixup_reorder_chain contains questionable code to cope with a
> pathological case:
>
> /* The degenerated case of conditional jump jumping to the next
>instruction can happen on target having jumps with side
>effects.
>
>
> I modified the gcc i386 backend. Now my gcc optimizes function prologue
>
> movq%rbx, -16(%rsp)
> movq%rbp, -8(%rsp)
> subq$16, %rsp
>
> to
> movq%rbx, -16(%rsp)
> movq%rbp, -8(%rsp)
> pushq %rax
> pushq %rax
>
> The change was
> On Wed, Nov 16, 2005 at 02:26:28PM -0800, Mark Mitchell wrote:
> > > http://gcc.gnu.org/projects/lto/lto.pdf
> >
> > Section 4.2
> >
> > What is the rationale for using a stack-based representation rather
> > than a register-based representation? A infinite register based
> > solution
>
> > Which is why i said "It's fine to say compile time performance of the
> > middle end portions ew may replace should be same or better".
> >
> > And if you were to look right now, it's actually significantly better in
> > some cases :(
>
> Can you prove this assertion?
>
> Here is some dat
> Jan Hubicka wrote:
> >I should note that comparison to ICC is not quite fair since it lacks
> >Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an invalid comparison.
>
> In my
>
> I have added FDO runs to the daily tramp3d tester and am observing
> "intersting" things there. First of all, compile time with
> -fprofile-generate (w/o leafify) skyrocketed from ~120s to 440s.
> For reference, here's the hot spots in -ftime-report:
>
> life analysis : 24.66 ( 6%)
> Steven Bosscher wrote:
> > Hi rth,
> >
> > The stack space sharing you added to cfgexpand.c breaks RTL alias
> > analysis.
> >
> > For example, the attached test case breaks for pentiumpro at -O2.
> > The problem apparently is that the second store to c is moved up
> > before before the load.
> I just found this in tree-cfg.c; the comment is probably wrong with
> respect to const and pure. What do you think?
Yes, it should be safe to remove the hack now when we do IPA profiling.
Thanks for noticing it ;)
Honza
>
> /* Return true if we need to add fake edge to exit at statement T.
>
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
> > ____
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
> 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
> >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
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
> 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
> 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
> 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
> 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
> > 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
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
> 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
> 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 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
> > > >
> > 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, 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
> > 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
> > > >
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
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.
> > 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
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
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
>
> 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
> 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
> > 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
> > + 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
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
> 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 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]
> 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
> 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
> 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 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
> >
> > 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 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.
>
>
> 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
> 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
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
> 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. Th
> > 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
> @@ -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
rul
> > 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 fi
> 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
> > > > builtin
>
> On Mon, Jan 11, 2016 at 1:38 AM, Kugan
> 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
> > to see in gcc. So my question is, i
> 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,
> >> cgraph_node::get_untransformed_body ()
> >> is called twice for node
> 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 something that can feed sane loop
>
> 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 whic
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:
>
> 2016-05-02 Jan Hubicka
>
>
> >
> > typeinfo seems to be a weak object symbol
> > which is known to be broken with lto, so
> > this may be related to:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69271
This PR is about quite speicfic use of weak symbols, the way weaks are used
in C++ (to unify multiple defintions) sh
> 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 alignment
> 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) - i
> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site. If type information
> indicates that it is not, devirt marks the site as unreachable. I
> think this is wrong, and it breaks some programs. At least, it should
> not do this if the
> On 04/25/2014 03:14 PM, Volker Simonis wrote:
> > Could you therefore please re-categorize this as devirt bug.
>
> It is an IPA bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
Now when I have interest from ubsan direction, I wanted to ask. Would it make
sense to turn
those unreachables
> On Fri, Apr 25, 2014 at 08:23:22PM +0200, Jan Hubicka wrote:
> > > On 04/25/2014 03:14 PM, Volker Simonis wrote:
> > > > Could you therefore please re-categorize this as devirt bug.
> > >
> > > It is an IPA bug. http://gcc.gnu.org/bugzilla/show
> On 05/20/14 04:09, Bruce Adams wrote:
> >Hi, I've been tracking the latest releases of gcc since 4.7 or so
> >(variously interested in C++1y support, cilk and openmp). One thing
> >I've found hard to locate is information about planned inclusions for
> >future releases. As much relies on unpredic
> The fix is attached. Ok to commit?
OK,
thanks!
Honza
> On 25 June 2014 10:26, Bingfeng Mei wrote:
> > Why is GCC code size so much bigger than LLVM? Does -Ofast have more
> > unrolling
> > on GCC? It doesn't seem increasing code size help performance (164.gzip &
> > 197.parser)
> > Is there comparisons for O2? I guess that is more useful for typic
> On 15 July 2014 15:43, Jan Hubicka wrote:
> > I also noticed that GCC code size is bigger for both firefox and
> > libreoffice.
> > There was some extra bloat in 4.9 compared to 4.8.
> > Martin did some tests with -O2 and various flags, perhaps we could trottle
&g
> > Hello,
> >thank you for you advice. It really looks that I face the same issue as
> > you seen. As you suggested, I will start with a global pointer to symtab and
> > we'll see further integration into context class (where it should reside
> > according to me).
>
> Note that I would sugges
> Thank you for your answer. I find the most time consuming process in
> compiling a file is the optimization of the cgraph nodes (execute
> all_passes),
> This process is sequence, one node by one node. If we divide the cgraph nodes
> into unrelated forest, we can parallel it, is this way feas
>
> As a First step I compared the "objump -D" dump between
> "stage2-gcc/gimple.o" and "stage3-gcc/gimple.o". Differences are in
> LTO sections .gnu.lto_.decls.0, .gnu.lto_.symtab.
> Ref: http://paste.ubuntu.com/7949238/
If you see the differences already in .o files (i.e. at compile time), I
> Hi Honza,
>
> I did not find any differences in tree level dumps. These are the dump
> differences in IPA
>
> In gimple-fold.c.000i.cgraph
>
> (--Snip--)
> < _Z25gimple_build_omp_continueP9tree_nodeS0_/761
> (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff7ebda548
> ---
> > _Z25gimp
> So... I've been getting my feet wet with LTO and debugging and I
> noticed a seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
>
> I've compared the dwarf output with and without LTO, and I noticed
> that the DW_TAG_lexical_block is miss
> On Fri, Aug 15, 2014 at 10:08:38PM +0200, Steven Bosscher wrote:
> > On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> > > So... I've been getting my feet wet with LTO and debugging and I noticed a
> > > seemingly unrelated yet annoying problem. On x86-64,
> > > gcc.dg/guality/pr48437.c f
>
> The following seems to fix it. In testing now.
Will streaming as non-reference prevent DECL from being merged and tails of
BLOCK_VAR chains
to be corrupted?
Honza
>
> Richard.
>
> > Richard.
> >
> >> Thanks.
> >> Aldy
gt; >> < vec::qsort(int (*)(void const*, void
> >> const*)) (struct vec * const this, int (*) (const void *, const
> >> void *) cmp)
> >> ---
> >>> vec::qsort(int (*)(void const*, void
> >>> const*)) (struct vec * const this, int (*) (const voi
> On August 18, 2014 8:46:00 PM CEST, Jan Hubicka wrote:
> >>
> >> The following seems to fix it. In testing now.
> >
> >Will streaming as non-reference prevent DECL from being merged and
> >tails of BLOCK_VAR chains
> >to be corrupted?
>
>
> On 09/03/14 02:35, Steven Bosscher wrote:
> >On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
> >>Last time I tried, there are several passes after loop_done and before
> >>auto-inc-dec can't handle auto-increment addressing mode, including
> >>fweb.
> >
> >It surprises me that pass_web can't han
Hi,
I went through excercise of running LTO bootstrap with ODR verification on.
There are some typename clashes
I guess we want to fix. I wonder what approach is preferred, do we want to
introduce anonymous
namespaces for those?
Honza
../../gcc/tlink.c:62:16: warning: type ‘struct file_hash_e
>
> I am trying to access the virtual table.
> My pass is hooked after pass_ipa_pta.
>
> Consider Class A which contains virtual function.
> An object created as :
> A a;
> is translated in GIMPLE as
> struct A a;
>
> From variable "a" we can get its type which is "struct A".
> I tried t
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
>
> 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
> 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 copm
> 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
> 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
> Hello.
>
> I've been finalizing IPA ICF testing process and I met a condition
> for lto-bootstrap, where cgraph_node::verify encounters error:
>
> In WPA, I prove that gen_vec_initv16qi can be merged with
> gen_vec_initv2sf. In the following case, ale local calls are
> redirected:
>
> wh
> On Thu, Oct 02, 2014 at 09:52:31PM +0200, Jan-Benedict Glaw wrote:
> > It seems that a full bootstrap including Ada got broken somewhere in
> > the range of r215789 .. r215799.
>
> I'm bisecting it (on powerpc64-linux, where it also shows up); it needs
> full bootstrapping every time, so will be
> On Wed, Oct 29, 2014 at 12:53 PM, Tejas Belagod wrote:
> > On 29/10/14 09:32, Richard Biener wrote:
> >>
> >> On Tue, Oct 28, 2014 at 4:55 PM, Evandro Menezes
> >> wrote:
> >>>
> >>> While doing some benchmark flag mining on AArch64, I noticed that
> >>> -fpeel-loops was a mined option often.
> On Tue, Oct 28, 2014 at 4:55 PM, Evandro Menezes
> wrote:
> > While doing some benchmark flag mining on AArch64, I noticed that
> > -fpeel-loops was a mined option often. As a matter of fact, when using it
> > always, even without FDO, it seemed to raise most benchmarks and to leave
> > almost
> Hi Honza,
Hello,
>
> I experimented building Coremark with both PGO and LTO at -O3 level on
> Aarch64 machine. First I generated profiles using the recommended seeds in
> Coremark's readme.txt. Then compiled again with -O3 -flto and -fprofile-use.
>
> I tried using GCC Linaro compiler (septemb
Hi,
this is patch I commited to mainline
2014-11-22 Jan Hubicka
* ipa.c (symbol_table::remove_unreachable_nodes): Mark all inline clones
as having abstract origin used.
* ipa-inline-transform.c (can_remove_node_now_p_1): Drop abstract
origin check
> Thanks for the fix. Is it ok to backport it to gcc-4_9?
Yes, it is OK assuming that there are no problems with the patch for a week.
(it ought to be safe)
Honza
> Hello.
>
> I've just finished successfully chromium LTO build and there's list of mainly
> -Wodr warnings.
> I think some of them are false positives?
What of those you consider to be false?
I wonder if we can print just type name so we avoid using the wrong "struct" in
place of class...
>
>
> Hello All:
>
> The large functions are the important part of high performance application.
> They contribute to performance bottleneck with many
> respect. Some of the large hot functions are frequently executed but many
> regions inside the functions are cold regions. The large
> Function blo
Hi,
the warning about types of fields seems misplaced:
> ../../third_party/WebKit/public/platform/WebCryptoAlgorithmParams.h:295:0:
> warning: type ???struct WebCryptoEcKeyImportParams??? violates one definition
> rule [-Wodr]
> class WebCryptoEcKeyImportParams : public WebCryptoAlgorithmParams
> On 02/16/2015 07:27 PM, Jan Hubicka wrote:
> >Jason, I wonder if there is more informative way to print destructor during
> >LTO than as __comp_dtor?
>
> You could print the mangled name, and possibly run it through
> __cxa_demangle if it starts with _Z.
>
> >
> Hi,
>
> I have problems compiling xalan as part of spec2006 benchmark for aarch64,
> both native and cross.
> The issue arises when both -flto and -fprofile-generate are enabled during
> LTO.
> Compiling with the same flags for x86 has no problem.
> Also other projects for aarch64 compile with
==
GNU Tools Cauldron 2015
http://gcc.gnu.org/wiki/cauldron2015
Call for Abstracts and Participation
August 7 to 9,
Prague, Czech Republic
101 - 200 of 681 matches
Mail list logo
