public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/40436] [4.5/4.6 regression] 0.5% code size regression caused by r147852 Date: Sun, 14 Nov 2010 09:14:00 -0000 [thread overview] Message-ID: <bug-40436-4-CQIjbKip4K@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-40436-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436 --- Comment #41 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-11-14 09:06:41 UTC --- Created attachment 22389 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22389 preprocessed ext/super.c Hi, this testcase shows that we are no longer able to optimize away ext3_sops in sb->s_magic = (__builtin_constant_p((__u16)((es->s_magic))) ? ({ __u16 __x = (((es->s_magic))); ((__u16)( (((__u16)(__x) & (__u16)0x00ffU) << 8) | (((__u16)(__x) & (__u16)0xff00U) >> 8) )); }) : __fswab16(((es->s_magic)))); if (sb->s_magic != 0xEF53) { if (!silent) printk("<3>" "VFS: Can't find ext3 filesystem on dev %s.\n", bdevname(dev)); goto failed_mount; } The problem is that varpool code now expect that variable accesses are optimized out at the end of gimple queue instead of using TREE_SYMBOL_REFERENCED bit. In this case sb->s_magic shomehow manages to get undefined and in GIMPLE land we keep the conditional around, while in RTL land init-regs initialize it to 0 that consequently makes mount to always fail. I guess it is not real code quality bug since it happens only on undefined behaviour code, but we might consider doing initialization by zero sometime in gimple queue, too. Also I am not quite sure if we are not misoptimizing the code, it is convoluted.
next prev parent reply other threads:[~2010-11-14 9:07 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-40436-4@http.gcc.gnu.org/bugzilla/> 2010-11-10 2:36 ` hubicka at gcc dot gnu.org 2010-11-11 22:09 ` hubicka at gcc dot gnu.org 2010-11-13 18:53 ` hubicka at gcc dot gnu.org 2010-11-13 19:14 ` hubicka at gcc dot gnu.org 2010-11-14 9:14 ` hubicka at gcc dot gnu.org [this message] 2010-11-14 10:07 ` hubicka at gcc dot gnu.org 2010-11-14 11:23 ` hubicka at gcc dot gnu.org 2010-11-14 16:56 ` hubicka at gcc dot gnu.org 2010-11-14 18:00 ` rguenther at suse dot de 2010-11-19 8:24 ` hubicka at gcc dot gnu.org 2010-12-16 13:09 ` rguenth at gcc dot gnu.org 2011-04-28 14:58 ` [Bug tree-optimization/40436] [4.5/4.6/4.7 " rguenth at gcc dot gnu.org 2011-09-09 14:51 ` steven at gcc dot gnu.org 2009-06-13 22:35 [Bug tree-optimization/40436] New: [4.5 " rearnsha at gcc dot gnu dot org 2010-07-31 9:35 ` [Bug tree-optimization/40436] [4.5/4.6 " rguenth at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-40436-4-CQIjbKip4K@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).