https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #41 from Aldy Hernandez ---
Created attachment 59181
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59181&action=edit
unrtested patch sorting threadable paths
The performance improvement with this patch is:
** mainline
Time v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #40 from Aldy Hernandez ---
For the record, I still think adjust_paths_after_duplication() isn't giving us
much for all the hassle it's causing.
I compared the number of threaded paths with and without it and the difference
is:
* m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #39 from Aldy Hernandez ---
I'm going to step away from this PR for a few weeks so I'll do a brain dump on
where I am, just in case someone wants to poke at it some more.
This problem in adjust_paths_after_duplication() boils down t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #36 from Aldy Hernandez ---
(In reply to Richard Biener from comment #33)
> Can we just sort m_paths after the path entry BB and fix the lookup that way?
This seemed promising, especially because the adjust_paths_after_duplication()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #35 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #34)
> Btw, if we simply remove the call to that function, with -O1
> -fenable-tree-thread1 I see:
>
> backwards jump threading : 14.36 ( 3%) 0.39 (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
Aldy Hernandez changed:
What|Removed |Added
CC||law at gcc dot gnu.org
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #26 from Aldy Hernandez ---
I think there's something fundamentally wrong in the *backwards* threader that
causes us to blow up, even without fully resolving conditions with a global
ranger.
I tried running at -O1 and -fenable-tree-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #25 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
Avoiding unnecessary recursion in simplify_control_stmt_conditi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #24 from Aldy Hernandez ---
(In reply to Richard Biener from comment #13)
> Most of the -O1 dom time is spent in threading using path ranger to simplify
> the JT conditions. That in turn does (for each threading from scratch?)
> GOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #23 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #22)
> Created attachment 59001 [details]
> reduce recursion in forward threader (patch in testing)
>
> As suggested by Richard in PR116166.
Should've been more v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #22 from Aldy Hernandez ---
Created attachment 59001
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59001&action=edit
reduce recursion in forward threader (patch in testing)
As suggested by Richard in PR116166.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #30 from Aldy Hernandez ---
(In reply to Richard Biener from comment #15)
> We're also doing a lot of redundant stmt simplifications by likely
> quadratically
> exploring jump threading paths. And each hybrid_jt_simplifier::simplif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115221
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
--- Comment #7 from Aldy Hernandez ---
Created attachment 58272
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58272&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> Confirmed.
>
> /* After the optimization PHI result can have value
> which it couldn't have previously. */
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115191
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115131
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115131
--- Comment #5 from Aldy Hernandez ---
Created attachment 58224
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58224&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115131
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
--- Comment #3 from Aldy Hernandez ---
Created attachment 58222
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58222&action=edit
patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115128
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #19 from Aldy Hernandez ---
(In reply to Richard Biener from comment #17)
> Handling pointer-vs-pointer in ptrs_compare_unequal isn't enough since we
> have
>
> # PT = nonlocal null
> unsigned int * x_7(D) = x;
> ...
> # PT = n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #32 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #31)
> > --- Comment #29 from Aldy Hernandez ---
> [...]
> > Ok, what's the minimum configuration I need to build here?
> >
> > srcdir/configure --b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #30 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #29)
> > > gmake[3]: Leaving directory '/home/aldyh/bld/clean'
> > > Comparing stages 2 and 3
> > > Bootstrap comparison failure!
> > > gcc/tree-vect-stmts.o diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #29 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #28)
> > --- Comment #27 from Aldy Hernandez ---
> > This is in cfarm216.cfarm.et:
> >
> > aldyh@s11-sparc:~/bld/clean$ hostname
> > s11-sparc.cfarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #27 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #26)
> > --- Comment #25 from Aldy Hernandez ---
> > prange has been enabled again, after testing on x86-64 and ppc64le linux.
> > Aarch has no spa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #25 from Aldy Hernandez ---
prange has been enabled again, after testing on x86-64 and ppc64le linux.
Aarch has no space to run tests on the compile farm, and sparc bootstrap was
already broken.
The problem in this PR can be trigge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #22 from Aldy Hernandez ---
(In reply to Martin Jambor from comment #20)
Thanks for looking into this.
> The IL we generate the jump function from is:
>
> _1 = cclauses_2(D) != 0B;
> c_parser_omp_all_clauses (_1);
>
> Which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #13 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #10)
> Created attachment 58202 [details]
> proof of concept implementing a range-op entry for builtin_assume_aligned
>
> Something like this (properly coded and e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #11 from Aldy Hernandez ---
Just to clarify. prange as well as irange keep a value/mask pair where we can
store alignment info, so every calculation (range-op) along the way can track
this properly.
Now, for pointers we loose this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #10 from Aldy Hernandez ---
Created attachment 58202
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58202&action=edit
proof of concept implementing a range-op entry for builtin_assume_aligned
Something like this (properly code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114995
--- Comment #9 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> The above examples just show misunderstanding what __builtin_assume_aligned
> is and what it is not. You need to use the result of the built-in function
> in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #18 from Aldy Hernandez ---
Ah, it looks like seurer already beat me to the preprocessed source.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #17 from Aldy Hernandez ---
(In reply to Martin Jambor from comment #16)
> I'll have look, hopefully on Monday.
Thanks Martin.
To reproduce the problem:
1. Revert this patch:
commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 (maste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #8 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #7)
> So what's the magic to re-enable prange? I can do that and spin a fresh
> build.
You could revert this patch:
commit d7bb8eaade3cd3aa70715c8567b4d7b08098e69
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Aldy Herna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #4 from Aldy Hernandez ---
Jeff, if you still have your tree around, could you try this patch?
I'll queue it with the rest of patches I will push before enabling prange when
the IPA issues are sorted out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #3 from Aldy Hernandez ---
Created attachment 58169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58169&action=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
--- Comment #2 from Aldy Hernandez ---
OK, this is embarrassing.
We are incorrectly folding a POINTER_PLUS_EXPR range operation:
Folding statement: x_7 = 2048B + _2;
-Queued stmt for removal. Folds to: 2062B
+Queued stmt for removal. Folds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115026
Bug ID: 115026
Summary: msp430-elf fails gcc.dg/pr66444.c with prange enabled
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #12 from Aldy Hernandez ---
Created attachment 58168
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58168&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #11 from Aldy Hernandez ---
I have reverted the prange enabling patch until the IPA pass is fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #10 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #9)
> The patch in comment 6 succeeds for me, but it seems more of a heavy-handed
> band-aid that confirms the symptom, but covers up the problem.
>
> Something in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
--- Comment #11 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #8)
> And on msp430-elf we're getting a codegen correctness issue on msp430-elf.
> gcc.dg/pr66444.c fails in the simulator. The -O2 code difference looks like:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
--- Comment #10 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #7)
> For rl78:
> static scalar_int_mode
> rl78_addr_space_address_mode (addr_space_t addrspace)
> {
> switch (addrspace)
> {
> case ADDR_SPACE_GENERIC:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115009
Aldy Hernandez changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #16 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > --- Comment #13 from Aldy Hernandez ---
> > BTW, I'm waiting for a review, or at least a nod from a C++ savvy person
> > here:
> >
> > htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #15 from Aldy Hernandez ---
Created attachment 58136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58136&action=edit
proposed patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #6 from Aldy Hernandez ---
I wonder if something like this would work.
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 5781f50..ea8a685 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -1730,6 +1730,8 @@ ipa_value_range_from_jfunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #13 from Aldy Hernandez ---
BTW, I'm waiting for a review, or at least a nod from a C++ savvy person here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650634.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
Aldy Hernandez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #2 from Aldy Hernandez ---
Yeah, that's mine.
Can you attach a preprocessed file of the offending file?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #12 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #10)
> If Aldy does not fix it by Saturday, I will give the union a try then. I
> will also try out the solaris machine on the compile farm if possible.
Sorry, didn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114912
--- Comment #1 from Aldy Hernandez ---
Since this happens while building libgcc during stage1, perhaps this can be
reproduced with a cross? Would it be possible to get the preprocessed file
that's failing?
You could try /var/gcc/reghunt/sigbus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111864
--- Comment #3 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #2)
> It almost looks like a costing issue. The threaders find opportunities to
> thread all the incoming edges in the key block to the path which avoids the
> call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #13 from Aldy Hernandez ---
I think y'all have it all figured out. Basically,
operator_cast::op1_range() is solving num_5 in the equation:
[111,111] = (short int) num_5
Where lhs is:
(gdb) p debug(lhs)
[irange] short int [111, 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Actually, looking at value-range.h, irange_bitmask doesn't have just the
> > mask but also value, so I wonder w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #18 from Aldy Hernandez ---
(In reply to rguent...@suse.de from comment #17)
> On Wed, 21 Feb 2024, aldyh at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
> >
> > --- Comment #8 from Aldy Hernande
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Aldy Hernandez from comment #11)
> > Both patches pass test. Up to the release maintainers to decide if they
> > want to include them in this re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #11 from Aldy Hernandez ---
Both patches pass test. Up to the release maintainers to decide if they want
to include them in this release. Otherwise, I'll queue them up for later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #10 from Aldy Hernandez ---
Created attachment 57478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57478&action=edit
Remove GTY support for vrange and friends
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #9 from Aldy Hernandez ---
Created attachment 57477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57477&action=edit
Remove virtual from int_range destructor.
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #8 from Aldy Hernandez ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Jambor from comment #4)
> > The right place where to free stuff in lattices post-IPA would be in
> > ipa_node_params::~ipa_node_params() wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #7 from Aldy Hernandez ---
Let me see if I can untangle things here. Thanks for chasing
this down, BTW.
Value_Range doesn't need a CTOR because it has an int_range_max which
does have one (courtesy of int_range<>), so things get in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113752
Aldy Hernandez changed:
What|Removed |Added
CC|aldyh at redhat dot com|
--- Comment #3 from Aldy Herna
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #6 from Aldy Hernandez ---
Created attachment 57336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336&action=edit
Proposed patch #2
Thanks for the suggestion Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #4 from Aldy Hernandez ---
Created attachment 57335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57335&action=edit
Proposed patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #2 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #1)
> Slightly tweaked, still -O1:
> char b;
> void bar (void);
>
> void
> foo (_BitInt(6110) j)
> {
> for (;;)
> {
> _BitInt(10) k = b % j;
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110603
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
--- Comment #7 from Aldy Hernandez ---
Created attachment 57016
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57016&action=edit
preprocessed testcase with GCC13
Compile with -O2 -std=c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111458
--- Comment #4 from Aldy Hernandez ---
(In reply to Richard Biener from comment #3)
> This issue is still latent in the forward threader. The backward threader
> calls this function from back_threader_profitability::profitable_path_p,
> so bef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468
--- Comment #6 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk.
Sweet. Thanks so much. This really helps.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111468
Bug ID: 111468
Summary: cannot express unordered equal in gimple FE
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110875
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110753
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110753
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
Ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107043
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107053
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228
--- Comment #17 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #4)
> Phiopt does this:
> ```
> v_13 == 1 ? 1 : LookupFlags_6
> Matching expression match.pd:1990, gimple-match-5.cc:23
> Matching expression match.pd:1990, gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #4 from Aldy Hernandez ---
FWIW, a less intrusive and probably more correct way of seeing what ranger
knows at this point would be to put a breakpoint where you're seeing:
Queued stmt for removal. Folds to: 2147483647
This is in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110233
--- Comment #3 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #2)
> VRP2/DOM3 produces the wrong folding for some reason:
> Folding statement: _27 = b.6_9 * 2;
> Queued stmt for removal. Folds to: 2147483647
>
> I don't uinder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #38 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #37)
> (In reply to CVS Commits from comment #36)
>
> > For the curious, a particular hot spot for IPA in this area was:
> >
> > ipcp_vr_lattice::meet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
--- Comment #3 from Aldy Hernandez ---
Created attachment 55140
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55140&action=edit
untested patch in testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109934
Aldy Hernandez changed:
What|Removed |Added
CC||amacleod at redhat dot com
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
Aldy Hernandez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109920
--- Comment #2 from Aldy Hernandez ---
Created attachment 55137
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55137&action=edit
untested patch
Does this fix the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #4 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #2)
> > If irange::supports_p (TREE_TYPE (arg)) is true, we're talking about an
> > integer/pointer, but if range_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
--- Comment #2 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #1)
> Breakpoint 6, range_cast (r=..., type=) at
> /home/apinski/src/upstream-gcc/gcc/gcc/range-op.cc:4853
> 4853 Value_Range tmp (r);
>
>
> Confirmed.
> The c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #6 from Aldy Hernandez ---
> but the issue with the PHI node remains unless we sink the &str part
> (but there's many uses of __i_14). I guess it's still the "easiest"
> way to get rangers help. Aka make
>
> # __i_14' = PHI <1(1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #4 from Aldy Hernandez ---
BTW, another reason I had to drop the prange work was because IPA was doing
their own thing with ranges outside of the irange API, so it was harder to
separate things out. So really, all this stuff was rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109791
--- Comment #3 from Aldy Hernandez ---
(In reply to Richard Biener from comment #2)
> Confirmed. This is a missed optimization, we fail to optimize the loop guard
>
> [local count: 329643239]:
> _4 = (unsigned long) &MEM [(void *)&str + 2B];
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695
--- Comment #35 from Aldy Hernandez ---
We could also tweak the number of sub-ranges. 8 (??) also sounds good for a
few percent less in performance drop, if we care.
p.s. I did try the auto_vec thing for a 25% loss in VRP performance, even whe
1 - 100 of 752 matches
Mail list logo
