https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #8 from Andrew Macleod ---
Final version of the patch is submitted to the mailing list (
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/681252.html ) which
removes adjust_range() and moves the same functionality directly into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #7 from Andrew Macleod ---
Bah. almost but not quite.
Rangers cache algorithm must remain as it is... it will always produce a better
result.. but we need to calculate everything properly.
Going back to the original analysis:
FWD v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119712
--- Comment #4 from Andrew Macleod ---
The change tweaks an issue that I haven't seen in the cache before.
When it is propagating values in the cache (the only real iteration ranger has)
the values are always suppose to get "better", and in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118167
--- Comment #6 from Andrew Macleod ---
(In reply to Sam James from comment #5)
> I suppose it's a job for prange?
I don't think so. I think it related to integral values being bumped by 1, and
pointer values being bumped by 4.
It seems the iv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #11 from Andrew Macleod ---
Created attachment 60905
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60905&action=edit
potential patch
(In reply to Sam James from comment #10)
> The testcase from https://gcc.gnu.org/bugzilla/sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119471
Andrew Macleod changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119439
Bug 119439 depends on bug 117287, which changed state.
Bug 117287 Summary: [13 Regression] assume attribute related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118922
--- Comment #12 from Andrew Macleod ---
Hmm. Going into phiopt2, I see:
[local count: 1014686024]:
if (h_6 != 0)
goto ; [94.50%]
else
goto ; [5.50%]
[local count: 114863530]:
# h_6 = PHI <0(4), 1(5)>
[local count: 1073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570
--- Comment #9 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #2)
> I think this is a duplicate of PR106379 . At the VRP2 stage I see:
>
>[local count: 1073741824]:
> if (c_6(D) == s_7(D))
> goto ; [34.00%]
> els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114589
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Bug 88575 depends on bug 110199, which changed state.
Bug 110199 Summary: [12/13 Regression] Missing VRP transformation with MIN_EXPR
and known relation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 88575, which changed state.
Bug 88575 Summary: gcc got confused by different comparison operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88575
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #9 from Andrew Macleod ---
I believe this is fixed by the same patch as I committed for 88575.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117424
--- Comment #10 from Andrew Macleod ---
It also works if I use
--disable-tree-cunroll
which makes me suspicious of cunroll.
It also works if I use
--fdisable-tree-evrp --fdisable-tree-vrp1
So I thought perhaps VRP is doing something to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #11 from Andrew Macleod ---
(In reply to Richard Biener from comment #8)
> (In reply to Richard Biener from comment #7)
> > I'm talking about the number of iterations of the second loop (after loop
> > splitting), the niter expressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117875
--- Comment #6 from Andrew Macleod ---
(In reply to Richard Biener from comment #5)
> I tried get_range_query (cfun)->range_of_expr (vr, niter->niter, stmt) with
> (unsigned int) M_9(D) - (unsigned int) k_24 and an enabled ranger
> but that inde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
--- Comment #7 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #6)
> > void digits_2.isra (integer(kind=4) ISRA.6607)
> > {
> > integer(kind=4) ISRA.6607_927(D) = ISRA.6607;
> > ...
> > # RANGE [irange] integer(kind=4) [-2147
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117088
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116753
--- Comment #5 from Andrew Macleod ---
Theres room for some improvement in relations via PHIs that I will document
here so I don't lose it. in VRP1 I see:
Registering value_relation (x_7 > x_4) (bb5) at x_7 = x_4 + 1;
Registering value_relati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117398
--- Comment #3 from Andrew Macleod ---
(In reply to Sam James from comment #2)
> * With just -O1, 11 works and >=12 fails, bisected to
> r12-2591-g2e96b5f14e4025.
> * With -O2 -fno-thread-jumps, 12 works and >=13 fails. Needs bisection I
> guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
Andrew Macleod changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117287
--- Comment #2 from Andrew Macleod ---
It seems that until now, we didn't see an empty block feeding a PHI that
mattered:
_3 = x_2(D) + 4294967292;
if (_3 <= 1)
goto ; [41.00%]
else
goto ; [59.00%]
goto ; [100.00%]
_6 = x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222
--- Comment #8 from Andrew Macleod ---
pointer_diff depends on range_operator::fold_range to do the generic fold,
which invokes wi_fold on subranges. It also in turn invokes
op1_op2_relation_effect.
This worked fine when pointers were implemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #10 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #9)
> Andrew, do you plan to backport this?
Wasn't planning to. Although the fast VRP pass exists in GCC 14, there is no
way to call it or test it. There were also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117222
--- Comment #6 from Andrew Macleod ---
(In reply to Sam James from comment #3)
> (In reply to Sam James from comment #2)
> > [...]
> > I'm very surprised by this as I was under the impression the prange stuff
> > was an initial stub (new class o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #10 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 59238 [details]
> gcc15-pr116899.patch
>
> Untested fix in patch form.
Also pre-approved.
thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 59236 [details]
> gcc15-pr116898.patch
>
> So like this? Will test tonight.
perfect. consider it pre-pproved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #7 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Even if create (n) didn't work (which would be good to debug), the
> > x.safe_grow_cleared (n); x.truncate (0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> Even if create (n) didn't work (which would be good to debug), the
> x.safe_grow_cleared (n); x.truncate (0); can be just done more efficiently
> with x.reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116899
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Similarly to the other BB, enable_ranger -> gimple_ranger -> ranger_cache
> does
> 1000m_workback.create (0);
> 1001m_workback.safe_grow_cleared (last_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116898
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> The bitint lowering pass emits some gimple statements on edges
> (gsi_insert_on_edge) and the edge insertions are (intentionally) committed
> to edges only at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #57 from Andrew Macleod ---
FWIW, on my last run, enabling early VRP sped up my -O1 compilation by a fair
amount. total compilation dropped from 480 seconds to 380 seconds...
It took 2.5 seconds to run, and im going to guess might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #55 from Andrew Macleod ---
(In reply to Richard Biener from comment #50)
> (In reply to Richard Biener from comment #4)
> > Trunk at -O1:
> >
> > dominator optimization : 495.14 ( 82%) 0.20 ( 5%) 495.44 (
> > 81%)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116588
--- Comment #3 from Andrew Macleod ---
Its happening in tree-ssa-propagate.cc after the simplification:
/* If this is a control statement the propagator left edges
unexecuted on force the condition in a way consistent with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #34 from Andrew Macleod ---
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 ( 5%) 14.68 ( 3%)
238M ( 9%)
which is a notable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #29 from Andrew Macleod ---
Huh. Do we calculate *all* paths ahead of time?
I tried running valgrind, which died, but up to that point it showed 77% of the
time spend in the body of
back_jt_path_registry::adjust_paths_after_duplica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #27 from Andrew Macleod ---
(In reply to Aldy Hernandez from comment #26)
>
> With -O1 -fenable-tree-thread1 (no threadfull):
> dominator optimization : 127.76 ( 7%) 0.57 ( 7%) 128.58 (
> 7%) 236M ( 9%)
> back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116003
Andrew Macleod changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #20 from Andrew Macleod ---
I did an -O2 run after those patches.
Highlights:
tree SSA incremental : 117.74 ( 1%) 0.63 ( 3%) 120.37 ( 1%)
1049M ( 24%)
dominator optimization : 680.49 ( 5%) 0.65
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #19 from Andrew Macleod ---
(In reply to GCC Commits from comment #17)
> The master branch has been updated by Andrew Macleod :
>
> https://gcc.gnu.org/g:9e4da946c4263a4c89d5fc365b3c97ae244c5018
>
> commit r15-2858-g9e4da946c4263a4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #23 from Andrew Macleod ---
(In reply to Richard Biener from comment #20)
> collected sofar. I've noticed with the backwards threader that path
> ranger isn't very good in the ability to preserve a cache when adding
> blocks. But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116166
--- Comment #7 from Andrew Macleod ---
I think fixing 114855 will probably resolve this one too. Its a more
"managable" test case. I'm trying to have a look, but I am off next week so
it isn't imminent.
Meanwhile the "workaround" might be to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116003
--- Comment #1 from Andrew Macleod ---
When registering an equivalence, the oracle creates an initial equivalence for
an SSA_NAME with itself in the def block. This prevents dominator queries
from searching past the definition block.
In this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115951
--- Comment #3 from Andrew Macleod ---
I think I have a handle on it.
The issue is statements like
_80 = _79 == 0
where in ADA a a boolean type is 8 bits and GCC's default boolean type is 1
bit.
All through ranger we use the type of the LHS,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115241
--- Comment #2 from Andrew Macleod ---
(In reply to sadineniharish8446 from comment #0)
> The scripts in contrib/header-tools/ are breaks with python3.
> These scripts were for python2 and we did update it for python3 and sent the
> patches to g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115208
--- Comment #6 from Andrew Macleod ---
Created attachment 58287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58287&action=edit
proposed patch
I'm testing this patch, does it resolve your problem?
I forgot to free the gori_nmap object w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114985
--- Comment #21 from Andrew Macleod ---
(In reply to Martin Jambor from comment #20)
> (I also cannot prevent myself from ranting a little that it would
> really help if all the ranger (helper) classes and functions were
> better documented.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #8 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #7)
> LOoks like the primary culprits now are:
>
> dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 (
> 7%) 170M ( 4%)
> backwards jump t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111009
--- Comment #14 from Andrew Macleod ---
Created attachment 58134
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58134&action=edit
adjusted patch
(In reply to Richard Biener from comment #13)
> Andrew - this doesn't pick to gcc-13 because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #7 from Andrew Macleod ---
LOoks like the primary culprits now are:
dominator optimization : 666.73 ( 7%) 0.77 ( 2%) 671.76 ( 7%)
170M ( 4%)
backwards jump threading :7848.77 ( 85%) 21.04 ( 65%)7920.05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> I really don't know how GORI etc. works.
> But, if when the switch handling determines that _1 (the switch controlling
> expression) has [irange] [111, 111] M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #8 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Aldy Hernandez from comment #6)
> > You may want to look at:
> >
> > // Return the bitmask inherent in the range.
> >
> > irange_bitmask
> > iran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #5 from Andrew Macleod ---
(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 why it isn't able to figure this out.
> I'd think m_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114331
--- Comment #3 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #2)
> I thought we don't, if the testcase starts with
> void dummy (void);
> short int foo (void);
> int src(void) {
> short int num = foo ();
> switch(num){
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #23 from Andrew Macleod ---
Created attachment 57686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57686&action=edit
another patch
(In reply to Richard Biener from comment #22)
> (In reply to Andrew Macleod from comment #21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #21 from Andrew Macleod ---
(In reply to Richard Biener from comment #19)
>
> While ranger has a range_on_exit API this doesn't work on GENERIC expressions
> as far as I can see but only SSA names but I guess that could be "fixed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96564
--- Comment #15 from Andrew Macleod ---
(In reply to Richard Biener from comment #13)
> (In reply to Jeffrey A. Law from comment #12)
> > So I think we could solve this with a bit of help from the alias oracle. We
> > have the routine ptrs_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #15 from Andrew Macleod ---
(In reply to Richard Biener from comment #14)
> (In reply to Andrew Macleod from comment #13)
> >
> > We would have tripped over this earlier if SCEV or one of those other places
> > using range_of_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #13 from Andrew Macleod ---
Created attachment 57638
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57638&action=edit
patch
Ok, there were 2 issues with simply invoking range_of_stmt, which this new
patch resolves. IF we aren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
> Just looking at the generated code of #c0 with -O2 on x86_64, this regressed
> with
> r13-3596-ge7310e24b1c0ca67b1bb507c1330b2bf39e59e32
> Andrew, are you going
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #12 from Andrew Macleod ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Andrew Macleod from comment #9)
> > > Created attachment 57620 [details]
> > > proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #9 from Andrew Macleod ---
Created attachment 57620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57620&action=edit
proposed patch
Does this solve your problem if there is an active ranger? it bootstraps with
no regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113632
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > (In reply to rguent...@suse.de from comment #4)
> >
> > >
> > > What was definitely missing is consideration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114151
--- Comment #5 from Andrew Macleod ---
(In reply to rguent...@suse.de from comment #4)
>
> What was definitely missing is consideration of POLY_INT_CSTs (and
> variable polys, as I think there's no range info for those).
>
Ranger doesn't do a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114086
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Unfortunately doing the ((682 >> x) & 1) to x & 1 optimization in match.pd
> isn't possible, we can only use global ranges there and we need path
> specific ran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #47 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #46)
> (In reply to Jan Hubicka from comment #43)
> > > // See discussion here:
> > > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> > Discuss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #46 from Andrew Macleod ---
(In reply to Jan Hubicka from comment #43)
> > // See discussion here:
> > // https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
> Discussion says:
>
> "Once legacy evrp is removed, this won'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113879
--- Comment #2 from Andrew Macleod ---
Not so much a cycle issue as a backward propagation issue.
:
goto ; [INV]
:
_1 = (long unsigned int) j_10;
<..>
if (j_10 >= -1)
goto ; [INV]
else
goto ; [INV]
:
__builtin_trap (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102580
--- Comment #6 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #5)
> To be precise, expand_expr_divmod uses get_range_pos_neg for that during
> expansion (unless we'd e.g. somehow noted it in some very late pass before
> expansio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #3 from Andrew Macleod ---
Seems reasonable to me, adding BBS should be fine throughout. just don't
re-order them :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113716
--- Comment #4 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #3)
> Maybe ranger could figure out that at least one of the multiplication
> operands is zero in this case, because the second one is non-zero only if
> the first on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113475
--- Comment #4 from Andrew Macleod ---
yoinks. Not sure how I missed that. thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113440
--- Comment #2 from Andrew Macleod ---
(In reply to Richard Biener from comment #1)
> Yeah, looks like
>
> if (a+a < a)
>
> for unsigned doesn't register the appropriate range on the false edge.
_1 = a_5(D) * 2;
if (_1 < a_5(D))
goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110205
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Macleod changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
Andrew Macleod changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110251
--- Comment #11 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Anonymous from comment #9)
> > (In reply to Andrew Pinski from comment #1)
> > > dom3 :
> > > ```
> >
> > Could you please explain on how you to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
--- Comment #6 from Andrew Macleod ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > Even then, I wonder why ranger doesn't figure this out.
> > (x+1u) <= 2 ? x : 0
> > must have a range [-1, 1] a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113301
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110199
--- Comment #3 from Andrew Macleod ---
(In reply to Andrew Pinski from comment #2)
> I Kinda see how to implement this by creating
> operator_min::fold_range/operator_max::fold_range but I am still new on
> using these interfaces so I am not 100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #9 from Andrew Macleod ---
Created attachment 56790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56790&action=edit
auxially patch to avid the trap
refining a range is fine... the only issue we are really running into here
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #7 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > what do you mean? when a statement is changed, it may generate a different
> > range than it did before,
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112843
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #3)
> (In reply to Richard Biener from comment #2)
> > what?! Ick. It definitely shouldn't re-fold anything but only scrap caches
> > _at most_.
>
> So it does
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112788
--- Comment #2 from Andrew Macleod ---
(In reply to Kewen Lin from comment #1)
>
> ranger makes use of type precision directly instead of something like
> types_compatible_p. I wonder if we can introduce a target hook (or hookpod)
> to make ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #13 from Andrew Macleod ---
Created attachment 56735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56735&action=edit
patch
(In reply to Sam James from comment #12)
> Is the plan to backport to 11/12/13 or to leave it?
hmm. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #2 from Andrew Macleod ---
It seems like we set 'e' to 3 immediately at the start:
[local count: 1073741824]:
e = 3;
goto ; [100.00%]
and it is never changed again. However, when we load from 'e' later in the IL
[local cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #5 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #4)
>
> I think
> Value_Range vr (operand_type);
> if (TREE_CODE_CLASS (operation) == tcc_unary)
> ipa_vr_operation_and_type_effects (vr,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> Well, in this case the user explicitly told compiler not to do that by not
> using a prototype and syntax which doesn't provide one from the definition.
> It i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111922
--- Comment #7 from Andrew Macleod ---
Explicit casts would be no problem as they go through the proper machinery. The
IL for that case has an explicit cast in it.
_1 = (int) x_2(D);
foo (_1);
its when that cast is not present,and we try t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112509
Andrew Macleod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112509
--- Comment #2 from Andrew Macleod ---
the original switch is an unsigned value with precision of 3 bits, so 0..7 just
fits.
It gets translated to an int index during gimplification, but the case labels
are still precision 3 values.
find_case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
--- Comment #8 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)
Do you have to ask for max_stmt_execu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110540
--- Comment #3 from Andrew Macleod ---
EVRP figures out the j value can only be 0 or -9 and removes a few stmts as a
result, and simplifies the PHI, producing
[local count: 114863530]:
# j_12 = PHI <0(2), -9(6)>
[local count: 107374182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
--- Comment #7 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> VRP could use max_stmt_executions here (note it doesn't properly handle loop
> nests so the name is somewhat misleading)
Given some arbitrary statement S, how
1 - 100 of 646 matches
Mail list logo
