From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-497600-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 106509 invoked by alias); 20 Sep 2015 10:01: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
Received: (qmail 106440 invoked by uid 48); 20 Sep 2015 10:01:26 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/52394] SH Target: SH2A defunct bitops
Date: Sun, 20 Sep 2015 10:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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:
Message-ID: <bug-52394-4-SovrDfKkMq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52394-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52394-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: 2015-09/txt/msg01578.txt.bz2

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #2)
> 
> The code should actually be something like this:
>         mov.l   .L2,r2
>         bld     #0,r5
>         mov     #0,r0
>         bor.b   #5,@(0,r2)
>         bst.b   #5,@(0,r2)

Actually this might also result in unexpected side-effects when accessing
external hardware, because the volatile mem is accessed with 2x load and 1x
store.  So actually, this sequence can't be really used safely.

Moreover, it seems the code size improvements for those SH2A bitops are not so
big.  The above code is 14 bytes.  The same on non-SH2A could be:

        shlr    r5
        subc    r0,r0
        not     r0,r0
        and     #32,r0
        mov.l   .L5,r2
        mov.b   @r2,r1
        or      r0,r1
        mov.b   r1,@r2

which is 16 bytes.

And the SH2A version of that could be:
        bld     #0,r5
        mov     #0,r0
        bst     #5,r0
        mov.l   .L5,r2
        mov.b   @r2,r1
        or      r0,r1
        mov.b   r1,@r2

which is 14 bytes.

And of course, if GBR can be clobbered it gets down to 8 bytes:
        mov.l   .L5,r2
        ldc     r2,gbr
        mov     #0,r0
        or.b    #32,@(r0,gbr)