https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #20 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 23 12:38:03 2019
New Revision: 277321
URL: https://gcc.gnu.org/viewcvs?rev=277321&root=gcc&view=rev
Log:
PR debug/90231
* tree-ssa-loop-ivopts.c (get_debug_comput
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #19 from Jakub Jelinek ---
Created attachment 47068
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47068&action=edit
gcc10-pr90231.patch
Untested implementation of what I wrote above.
The difference on the testcase at -O2 -g is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #18 from rguenther at suse dot de ---
On Thu, 17 Oct 2019, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
>
> --- Comment #13 from Jakub Jelinek ---
> Sure, the debug stmts should not have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #17 from Jakub Jelinek ---
Note, for the ignoring of not useful candidates we could during the cand_pref
computation not just check for step being equal, but also if one step is
multiple of the other one or vice versa, of course prefe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #16 from Jakub Jelinek ---
So, one possibility is for remove_unused_ivs to get_computation_at for all
candidates it is considering rather than just the best, or try best and if that
fails, try the others too and pick the best from amo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #15 from Jakub Jelinek ---
That has been added for PR54693 BTW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #14 from Jakub Jelinek ---
Note, there already is a function that is meant to handle this,
remove_unused_ivs, just either it doesn't find the right IV candidate, or
get_computation_at fails.
On this particular testcase, I see 2 IVs in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #13 from Jakub Jelinek ---
Sure, the debug stmts should not have any effect on code generation. I admit I
don't know much about ivopts implementation, but either when you are rewriting
stmts containing uses of the IV being replaced b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #12 from bin cheng ---
(In reply to Jakub Jelinek from comment #10)
> Actually (int) ((ivtmp.11 - (unsigned long) dst_10) / 4), sorry.
> On 64-bit targets this will never be a problem, are you worried about 32-bit
> targets where int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #11 from bin cheng ---
(In reply to Richard Biener from comment #9)
> (In reply to bin cheng from comment #7)
> > The orignal iv needs to be represented in debug bind stmt is:
> > 64 IV struct:
> > 65 SSA_NAME: i_18
> > 66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #10 from Jakub Jelinek ---
Actually (int) ((ivtmp.11 - (unsigned long) dst_10) / 4), sorry.
On 64-bit targets this will never be a problem, are you worried about 32-bit
targets where int and pointers are the same width and for a loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #9 from Richard Biener ---
(In reply to bin cheng from comment #7)
> The orignal iv needs to be represented in debug bind stmt is:
> 64 IV struct:
> 65 SSA_NAME: i_18
> 66 Type: int
> 67 Base: 0
> 68 Step: 1
> 69 B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #8 from Jakub Jelinek ---
(In reply to bin cheng from comment #7)
> The orignal iv needs to be represented in debug bind stmt is:
> 64 IV struct:
> 65 SSA_NAME: i_18
> 66 Type: int
> 67 Base: 0
> 68 Step: 1
> 69 Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #7 from bin cheng ---
The orignal iv needs to be represented in debug bind stmt is:
64 IV struct:
65 SSA_NAME: i_18
66 Type: int
67 Base: 0
68 Step: 1
69 Biv: Y
70 Overflowness wrto loop niter: No-overflow
Whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
Bug 90231 depends on bug 90197, which changed state.
Bug 90197 Summary: [8 Regression] Cannot step through simple loop at -O -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90197
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
Carlo B. changed:
What|Removed |Added
CC||castro8583bennett at gmx dot
com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #4 from Jakub Jelinek ---
I think the order doesn't matter in this case, as debug stmts can't have PHIs
ATM and that is what you either immediately or soonish end up with.
The only thing it changes is IMHO whether the D#1 appears in t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #3 from rguenther at suse dot de ---
On April 24, 2019 5:04:37 PM GMT+02:00, "jakub at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
>
>Jakub Jelinek changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
--- Comment #2 from Alexandre Oliva ---
that's a known (to me) problem; it's mentioned in the gOlogy report, and IIRC I
even highlighted it in the slides about it
I spent some time looking for a low-hanging fix a while ago, but came out
empty-ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90231
Jakub Jelinek changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
Vers
21 matches
Mail list logo
