From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id F04E83858C5E; Sun, 16 Jul 2023 14:39:29 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F04E83858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1689518369;
	bh=0JO7gGc52A8Ff6f8FCsEbl0cqiPlR4HKWt86bHSwPd0=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=TpFjb88tQ9V+0/7rQkFcDQ829MMlN0UcPES9Ag1bvpZbjkguHNVnkZ3jE4p5GiTin
	 GuXis/iZt16dGG4SL9ZHLn9LNj76X8e7sVo+hEFU7XPh0c/V07g8KU/KAdGiR3JRqR
	 wH8zys4K5N4hIyTFBOrZiWpDniGrWEV6w7wCA74Y=
From: "tkoenig at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/68360] GCC bitfield processing code is very
 inefficient
Date: Sun, 16 Jul 2023 14:39:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: tkoenig at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: pinskia at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cf_reconfirmed_on cc
Message-ID: <bug-68360-4-4HKlDNV5Uy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-68360-4@http.gcc.gnu.org/bugzilla/>
References: <bug-68360-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2015-11-16 00:00:00         |2023-7-16
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #7 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Just stumbled across this.

A maybe simpler testcase:

typedef struct
{
  unsigned long x: 42;
  unsigned b: 1;
  unsigned long y: 42;
} myfield;

typedef struct
{
   unsigned long x: 7;=20=20
   unsigned b: 1;
   unsigned long y: 42;
} yourfield;

void foo(myfield *x)
{
  x->b =3D 1;
}

void bar (yourfield *x)
{
    x->b =3D 1;
}

gets, on RISC-V,

foo:
        ld      a5,0(a0)
        li      a4,1
        slli    a4,a4,42
        or      a5,a5,a4
        sd      a5,0(a0)
        ret
bar:
        ld      a5,0(a0)
        ori     a5,a5,128
        sd      a5,0(a0)
        ret

Using an indexed load byte/store byte would be an advantage for foo, at lea=
st.=