https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #24 from Jan Hubicka ---
I do not think there is problem with pdom for cyclic WRT acyclic paths. Both
notions are equivalent here.
If you have instruction I in, say, header of a loop and you determine it live
then the condition cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #23 from Richard Biener ---
Just for the record we had the idea to apply the "bolt" of marking the latch
control dependence (as done for possibly infinite loops) for loops containing
stmts with side-effects.
diff --git a/gcc/tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #22 from Michael Matz ---
Over the last days I came to a similar conclusion. Control dependence as
defined
with postdoms doesn't capture the number of invocations of an instruction, just
wether it's invoked at all. I.e. paths with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #20 from Richard Biener ---
(In reply to Michael Matz from comment #19)
> (In reply to Michael Matz from comment #18)
> > But there are other blocks control dependend on bb4, namely bb5 and bb9.
> > To see this observe that bb9 doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #19 from Michael Matz ---
(In reply to Michael Matz from comment #18)
> But there are other blocks control dependend on bb4, namely bb5 and bb9.
> To see this observe that bb9 doesn't pdom bb4, but there's a path from bb4 to
> bb9 (e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #18 from Michael Matz ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > Created attachment 50248 [details]
> > dot of the CFG as CD-DCE sees it
>
> (gdb) p debug_dominance_info (CDI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #17 from Michael Matz ---
(In reply to Richard Biener from comment #16)
> Of course since -ffinite-loops and the C++ standard require forward progress
> here and all testcases expect the loop to not terminate we're in the realm
> of u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #16 from Richard Biener ---
Of course since -ffinite-loops and the C++ standard require forward progress
here and all testcases expect the loop to not terminate we're in the realm of
undefined behavior. But I'm not yet convinced the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #15 from Richard Biener ---
Further simplified, but still depends on -ffinite-loops
volatile int xx;
int main()
{
int jobs_ = 1;
int at_eof_ = 0;
while (1)
{
for (int i = 0; i < jobs_; i++)
{
if (at_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #14 from Richard Biener ---
Oh, and the testcase does not require the abort () call but can do with a
regular exit and no unreachable blocks:
volatile int xx;
int main()
{
int read_finish_ = 1;
int jobs_ = 1;
int at_eof_ = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #13 from Richard Biener ---
Created attachment 50253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50253&action=edit
patch to streamline connect_infinite_loops_to_exit
I'm considering this patch to make connect_infinite_loops_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #12 from Richard Biener ---
So we can massage post-dom compute to make control dependence which is defined
in terms of pdom do what we want. We have
void
dom_info::calc_dfs_tree ()
{
...
/* In the post-dom case we may have nod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> Created attachment 50248 [details]
> dot of the CFG as CD-DCE sees it
(gdb) p debug_dominance_info (CDI_POST_DOMINATORS)
2 3
3 11
4 6
5 9
6 7
7 1
9 11
11 4
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #10 from Richard Biener ---
Created attachment 50248
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50248&action=edit
dot of the CFG as CD-DCE sees it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #9 from Richard Biener ---
Another fix for the finite-loop issue would be to avoid considering loops not
post-dominated by the exit block as finite. Like with the imperfect
diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #8 from Richard Biener ---
The following reduced testcase fails in the described way at -O2 with the C++
FE and with the C FE if you specify -ffinite-loops in addition to -O2. Already
CDDCE1 does the problematic transform which means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #7 from Richard Biener ---
So
@@ -1661,6 +1662,7 @@ perform_tree_ssa_dce (bool aggressive)
if (aggressive)
{
/* Compute control dependence. */
+ connect_infinite_loops_to_exit ();
calculate_dominance_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> If there are EH edges, doesn't it fit then the -ffinite-loops description:
> '-ffinite-loops'
> Assume that a loop with an exit will eventually take the exi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #4 from Jakub Jelinek ---
If there are EH edges, doesn't it fit then the -ffinite-loops description:
'-ffinite-loops'
Assume that a loop with an exit will eventually take the exit and
not loop indefinitely. This allows the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
--- Comment #3 from Rex <251078896 at qq dot com> ---
Dear Richard,
Your post is informative, but I can't follow them all. Where does those "", "basic block 14", "local count" come from? I'm very interested in this
kind of analysis (and tools). C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99101
Richard Biener changed:
What|Removed |Added
Version|og10 (devel/omp/gcc-10) |11.0
Status|UNCONFIRMED
24 matches
Mail list logo
