http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498
--- Comment #9 from davidxl <xinliangli at gmail dot com> 2011-07-07 19:31:53 UTC --- On Thu, Jul 7, 2011 at 9:23 AM, law at redhat dot com < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 > > --- Comment #8 from Jeffrey A. Law <law at redhat dot com> 2011-07-07 > 16:22:48 UTC --- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/05/11 16:52, xinliangli at gmail dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49498 > > > > --- Comment #7 from davidxl <xinliangli at gmail dot com> 2011-07-05 > 22:51:49 UTC --- > > (In reply to comment #6) > >> Created attachment 24693 [details] > >> k.c.127t.uninit > > > > > > 1) is the complicated control flow generated by if-merging + > jump-threading? > I think jump-threading is the primarly culprit. At one time I tried to > track how things changed through the passes, but ultimately decided the > end result either had to be analyzable or not by the uninit code. > > > 2) On the targets that have the problem, is branch cost considered cheap? > No idea. I didn't bother to look at why cris-elf triggers the problem, > but x86 doesn't. Presumably it's a branch-cost or similar issue. > > > 3) Looks like there are more jump-threading opportunities that can clean > up the > > control flow, namely, > Yes. Jump threading is inherently an iterative process. It was decided > some time ago to remove the iterative step as it doesn't buy a whole lot > in terms of code quality and it's a fairly significant compile-time cost. > Does it need to be iterative? Any simple example to show dependency of jump-threading analysis on actual transformation of some other jump-threading instance (e.g, opportunity only gets exposed after transformation)? > > During my investigations noticed the same thing and manually reran DOM > from within GDB and verified it further simplified the CFG, but > rerunning DOM isn't really going to be an option. > Is incremental DOM update a choice? David > > > > > > With the complicated control flow, the uninit analysis is definitely > confused > > -- requires powerful symbolic evaluation to simplify the predicates: the > > predicates guarding the use in BLOCK 6: > > > > (n<=9 AND m==0) OR (n <= 9 AND m != 0 AND (n <=9 OR m > 100)) OR (n > 9 > AND m > >> 100) OR (n > 9 AND m <= 100 AND (n<=9 OR m > 100)) > > > > of course there might be other bugs in the analysis that prevent the > above from > > formulated, but nonetheless, it is unlikely to be handled). > OK. That's kindof what I needed to know -- we're unlikely to handle > this particular case. > > > > > Solution > > 1) fix the test case by disabling jumpthreading and if-merging > Or xfailing it for the affected targets. > > > 2) or maybe move the uninit analysis earlier in the pipeline. > As you know, that runs the risk of introducing other false positives. > > I can live with #1 or the target-specific xfailing approach. > > jeff > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOFd1BAAoJEBRtltQi2kC7wpsIAJ1FStgYozE/6o8o5mZrj+5V > hWP7WmspSVFQMLTGDZw7hNeCEnE2rIl/8Tmin6/GDWM50oNGati2HqTRqTSZwU0y > YvMY8NlH1/YY4hJ94YPEpNrALAIwD8w3qdhiPVlS7eTWgOl8iTmXLJmJqk6OnT+Z > BeYPxpYDkQgYvicyjT4VVcWpwcmCbE/D9bKTNt68ABAH8RTmkba/VaK1wtGpt3qt > hy0qXCi59OUPh7TbcKvgrDLL3GDmy68C9afHUiEKyfDu3JxV9awl4y4Bfr1lOURF > bvTOuhKQo0MOlbtgJo24nGYK2TU/1Nv1DkcdhgvsCCBciO8LPoocnSZ176ohE5E= > =/ti9 > -----END PGP SIGNATURE----- > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. >