From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-237206-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21652 invoked by alias); 3 Dec 2007 02:44:19 -0000
Received: (qmail 21602 invoked by uid 48); 3 Dec 2007 02:44:07 -0000
Date: Mon, 03 Dec 2007 02:44:00 -0000
Message-ID: <20071203024407.21601.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-31081-6528@http.gcc.gnu.org/bugzilla/>
Subject: [Bug tree-optimization/31081] [4.3 Regression] Inliner messes up SSA for abnormals
In-Reply-To: <bug-31081-6528@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-12/txt/msg00137.txt.bz2



------- Comment #9 from pinskia at gcc dot gnu dot org  2007-12-03 02:44 -------
>>From PR 30604:
 OK, new investigation show that using the smaller testcase firebird2-nav.cc
shows the inliner is misbehaving. 

before inlining  (*041t.profile):

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.2709_4 = request_3(D)->req_pool;
  D.2710_5 = (struct blk *) D.2709_4;
  D.2711_6 = request_3(D)->req_transaction;
  D.2712_10 = VIO_get (tdbb_7(D), rpb_8(D), rsb_9(D), D.2711_6, D.2710_5);
  # SUCC: 4 (ab,eh,exec) 3 [100.0%]  (fallthru,exec)

  # BLOCK 3 freq:10000
  # PRED: 2 [100.0%]  (fallthru,exec)
  result_12(ab) = (BOOLEAN) D.2712_10;
<...>
  BTR_key (tdbb_7(D), D.2719_20, D.2718_19, D.2717_18, &value, 0B);
  goto <bb 5>;
  # SUCC: 4 (ab,eh,exec) 5 [100.0%]  (fallthru,exec)

  # BLOCK 4
  # PRED: 2 (ab,eh,exec) 3 (ab,eh,exec)
  # result_1(ab) = PHI <result_11(ab)(2), result_12(ab)(3)>
<L0>:;
  <...>

 # BLOCK 5 freq:10000
  # PRED: 3 [100.0%]  (fallthru,exec) 4 [100.0%]  (fallthru,exec)
  # result_2 = PHI <result_12(ab)(3), result_1(ab)(4)>
  return result_2;
  # SUCC: EXIT [100.0%]



and after inlining (*046i.inline) we see:



<bb 2>:

<bb 7>:
  D.2882_11 = request_9(D)->req_pool;
  D.2883_12 = (struct blk *) D.2882_11;
  D.2884_13 = request_9(D)->req_transaction;
  D.2885_14 = VIO_get (tdbb_8(D), rpb_3(D), rsb_1(D), D.2884_13, D.2883_12);

<bb 3>:
  result_15(ab) = (BOOLEAN) D.2885_14;
<...>
  BTR_key (tdbb_8(D), D.2892_22, D.2891_21, D.2890_20, &value, 0B);
  goto <bb 5>;

  # result_24(ab) = PHI <result_10(ab)(7), result_15(ab)(3)>
<L4>:;
<...>

<bb 5>:
  # result_23 = PHI <result_15(ab)(3), result_24(ab)(4)>
  if (result_23 != 0)
    goto <bb 6>;
  else
    goto <bb 7>;

<bb 6>:
  return 1;



Basic block 7 is missing a PHI node which should merge result_23 and result_10.
 The result of this missing PHI should then be used in block 5 instead of
result_10.

The way it currently sits, result 10 is live through basic block 3, which makes
it conflict with result_15, and makes the abnormal edges uncoalescable.

Someone familiar with the inliner can probably fix this quickly. I took a quick
look but its a different world in there :-)


-- 


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