public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND
@ 2013-02-28 14:41 ysrumyan at gmail dot com
  2013-02-28 14:43 ` [Bug lto/56483] " ysrumyan at gmail dot com
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: ysrumyan at gmail dot com @ 2013-02-28 14:41 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

             Bug #: 56483
           Summary: LTO issue with expanding GIMPLE_COND
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ysrumyan@gmail.com


If we compile attached simple test-case with -flto and -fno-inline we can see
the following sequence of rtl produced for or-ed condition:

;; if (_5 != 0)

(insn 18 17 19 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:QI 59 [ c ])
            (const_int 45 [0x2d]))) t1.c:12 -1
     (nil))

(insn 19 18 20 (set (reg:QI 66 [ D.2371 ])
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(insn 20 19 21 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:QI 59 [ c ])
            (const_int 43 [0x2b]))) t1.c:12 -1
     (nil))

(insn 21 20 22 (set (reg:QI 68 [ D.2371 ])
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(insn 22 21 23 (parallel [
            (set (reg:QI 69 [ D.2371 ])
                (ior:QI (reg:QI 66 [ D.2371 ])
                    (reg:QI 68 [ D.2371 ])))
            (clobber (reg:CC 17 flags))
        ]) t1.c:12 -1
     (nil))

(insn 23 22 24 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:QI 69 [ D.2371 ])
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(jump_insn 24 23 0 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 0)
            (pc))) t1.c:12 -1
     (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil)))
i.e. or-ed conditions were not ;; if (_5 != 0)

(insn 18 17 19 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:QI 59 [ c ])
            (const_int 45 [0x2d]))) t1.c:12 -1
     (nil))

(insn 19 18 20 (set (reg:QI 66 [ D.2371 ])
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(insn 20 19 21 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg/v:QI 59 [ c ])
            (const_int 43 [0x2b]))) t1.c:12 -1
     (nil))

(insn 21 20 22 (set (reg:QI 68 [ D.2371 ])
        (eq:QI (reg:CCZ 17 flags)
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(insn 22 21 23 (parallel [
            (set (reg:QI 69 [ D.2371 ])
                (ior:QI (reg:QI 66 [ D.2371 ])
                    (reg:QI 68 [ D.2371 ])))
            (clobber (reg:CC 17 flags))
        ]) t1.c:12 -1
     (nil))

(insn 23 22 24 (set (reg:CCZ 17 flags)
        (compare:CCZ (reg:QI 69 [ D.2371 ])
            (const_int 0 [0]))) t1.c:12 -1
     (nil))

(jump_insn 24 23 0 (set (pc)
        (if_then_else (eq (reg:CCZ 17 flags)
                (const_int 0 [0]))
            (label_ref 0)
            (pc))) t1.c:12 -1
     (expr_list:REG_BR_PROB (const_int 5000 [0x1388])
        (nil)))
i.e. condition was not splitted.

The problem is in gimple_cond_single_var_p (stmt) which return false since 0
(or 1) is not presented as boolean_false_node (boolean_true_node) but if we
change 
e.g.
    gimple_cond_rhs (gs) == boolean_false_node
to
    integer_zerop (gimple_cond_rhs (gs))

required splitting will happen.
Another way is to fix IR reader in lto.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug lto/56483] LTO issue with expanding GIMPLE_COND
  2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
@ 2013-02-28 14:43 ` ysrumyan at gmail dot com
  2013-03-01 11:00 ` [Bug middle-end/56483] " rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: ysrumyan at gmail dot com @ 2013-02-28 14:43 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

--- Comment #1 from Yuri Rumyantsev <ysrumyan at gmail dot com> 2013-02-28 14:43:22 UTC ---
Created attachment 29551
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29551
test-case to reproduce

Test must be compiled with -O2 -flto -fno-inline options


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
  2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
  2013-02-28 14:43 ` [Bug lto/56483] " ysrumyan at gmail dot com
@ 2013-03-01 11:00 ` rguenth at gcc dot gnu.org
  2013-03-01 11:03 ` rguenth at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-03-01 11:00 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Keywords|                            |lto, missed-optimization
   Last reconfirmed|                            |2013-03-01
          Component|lto                         |middle-end
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-01 11:00:18 UTC ---
gimple_cond_single_var_p should be inlined at its single caller, it isn't
any good abstraction.

integer_zerop isn't a good enough test for what the single caller tries to
assert as far as I can see.  You'd need to test whether it's precision
is 1 as well (or whether it's BOOLEAN_TYPE).

The IR reader cannot be fixed (the middle-end shouldn't use
frontend boolean_*_node) - frontends have different representation for their
boolean_{true,false,type}_nodes.

Well.  Confirmed and mine.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
  2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
  2013-02-28 14:43 ` [Bug lto/56483] " ysrumyan at gmail dot com
  2013-03-01 11:00 ` [Bug middle-end/56483] " rguenth at gcc dot gnu.org
@ 2013-03-01 11:03 ` rguenth at gcc dot gnu.org
  2013-03-18 10:31 ` rguenth at gcc dot gnu.org
  2013-03-18 10:31 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-03-01 11:03 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-01 11:03:24 UTC ---
Created attachment 29560
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29560
patch

Patch, queued for 4.9.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
  2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
                   ` (2 preceding siblings ...)
  2013-03-01 11:03 ` rguenth at gcc dot gnu.org
@ 2013-03-18 10:31 ` rguenth at gcc dot gnu.org
  2013-03-18 10:31 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-03-18 10:31 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-18 10:29:58 UTC ---
Author: rguenth
Date: Mon Mar 18 10:29:43 2013
New Revision: 196776

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196776
Log:
2013-03-18  Richard Biener  <rguenther@suse.de>

    PR middle-end/56483
    * cfgexpand.c (expand_gimple_cond): Inline gimple_cond_single_var_p
    and implement properly.
    * gimple.h (gimple_cond_single_var_p): Remove.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/gimple.h


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug middle-end/56483] LTO issue with expanding GIMPLE_COND
  2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
                   ` (3 preceding siblings ...)
  2013-03-18 10:31 ` rguenth at gcc dot gnu.org
@ 2013-03-18 10:31 ` rguenth at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-03-18 10:31 UTC (permalink / raw)
  To: gcc-bugs


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56483

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.9.0
         Resolution|                            |FIXED

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-18 10:30:40 UTC ---
Fixed.


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-03-18 10:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-02-28 14:41 [Bug lto/56483] New: LTO issue with expanding GIMPLE_COND ysrumyan at gmail dot com
2013-02-28 14:43 ` [Bug lto/56483] " ysrumyan at gmail dot com
2013-03-01 11:00 ` [Bug middle-end/56483] " rguenth at gcc dot gnu.org
2013-03-01 11:03 ` rguenth at gcc dot gnu.org
2013-03-18 10:31 ` rguenth at gcc dot gnu.org
2013-03-18 10:31 ` rguenth at gcc dot gnu.org

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).