[Bug target/51244] [SH] Inefficient conditional branch and code around T bit

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #60 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Laurent Aflonsi from comment #59)
> I have a functional regression due to this improvement when we are compiling
> the enclosed example in -O2.
>  $ sh-superh-elf-gcc -O2 pr51244-20-main.c pr51244-20.c
>  $ sh-superh-elf-run a.out
>  FAIL
> 
> Thus, the code is transformed from :
>   _get_request:
> 	mov.l	@(12,r4),r1
> 	tst	r1,r1
> 	bt	.L2
> 	mov.l	@(4,r4),r2
> 	tst	r2,r2
> 	mov	#-1,r2
>  	negc	r2,r2
>   .L3:
> 	tst	r2,r2
> 	bt/s	.L11
> 	mov	#-100,r0
>         mov	#1,r2
>         [...]
> 
> to : 
>   _get_request:
> 	mov.l	@(12,r4),r1
> 	tst	r1,r1
> 	bt	.L2
> 	mov.l	@(4,r4),r2
> 	tst	r2,r2
> 	mov	#-1,r2
> 	negc	r2,r2
>   .L3:
> 	bf/s	.L11
> 	mov	#-100,r0
>         mov	#1,r2
>         [...]
> 
> With the inputs encoded in the main function, we are supposed to follow the
> simpliest flow (no jump), but when this optimization is enabled, we are
> jumping to L11 to to the bt -> bf transfrmation.

The idea was that sequences such as
  tst r2,r2
  mov #-1,r2
  negc r2,r2
  tst r2,r2
  bt  ...

should be folded to
  tst r2,r2
  bt  ...

... if r2 is dead afterwards (which it seems to be).  I guess I missed to
handle some cases where the tested register is in a loop or can be reached by
some other basic block.  I'll check out the details.
>From gcc-bugs-return-426410-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 20 16:17:32 2013
Return-Path: <gcc-bugs-return-426410-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32147 invoked by alias); 20 Jul 2013 16:17:31 -0000
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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29879 invoked by uid 48); 20 Jul 2013 16:15:28 -0000
From: "ebotcazou at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57940] [PATCH] Rerun df_analyze after delete_unmarked_insns during DCE
Date: Sat, 20 Jul 2013 16:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ebotcazou at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-57940-4-vw01eVc78c@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57940-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57940-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg00917.txt.bz2
Content-length: 945

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW940

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-07-20
                 CC|                            |ebotcazou at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> If delete_unmarked_insns deletes some insn, DF state might be
> out of date, and, regs_ever_live might contain unused registers till the end.

I presume this occurs after reload?

> Fixed by forcing regs_ever_live update and rerunning df_analyze () at
> fini_dce().

No, calling df_compute_regs_ever_live (true) is incorrect after reload, see the
comment in rest_of_handle_df_initialize.