[Bug tree-optimization/66110] New: uint8_t memory access not optimized

[Bug tree-optimization/66110] New: uint8_t memory access not optimized

[kevin at koconnor dot net]

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

            Bug ID: 66110
           Summary: uint8_t memory access not optimized
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kevin at koconnor dot net
  Target Milestone: ---

It appears that gcc does not do a good job of optimizing memory accesses to
'uint8_t' variables.  In particular, it appears as if "strict aliasing" is not
done on uint8_t variables, and it appears it is not done even if the uint8_t is
in a struct.

============ GCC version:

$ ~/src/install-5.1.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/kevin/src/install-5.1.0/bin/gcc
COLLECT_LTO_WRAPPER=/home/kevin/src/install-5.1.0/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/home/kevin/src/install-5.1.0
--enable-languages=c
Thread model: posix
gcc version 5.1.0 (GCC) 

=========== Compile command line:

~/src/install-5.1.0/bin/gcc -v -save-temps -O2 -Wall u8alias.c -c

=========== Contents of u8alias.c:

typedef __UINT8_TYPE__ uint8_t;
typedef __UINT16_TYPE__ uint16_t;

struct s1 {
    uint16_t f1;
    uint8_t f2;
};

struct s2 {
    struct s1 *p1;
};

void f1(struct s2 *p)
{
    p->p1->f2 = 9;
    p->p1->f2 = 10;
}

=========== Contents of u8alias.i:

# 1 "u8alias.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 1 "<command-line>" 2
# 1 "u8alias.c"
typedef unsigned char uint8_t;
typedef short unsigned int uint16_t;

struct s1 {
    uint16_t f1;
    uint8_t f2;
};

struct s2 {
    struct s1 *p1;
};

void f1(struct s2 *p)
{
    p->p1->f2 = 9;
    p->p1->f2 = 10;
}

=========== Results of compilation:

$ objdump -ldr u8alias.o

0000000000000000 <f1>:
f1():
   0:   48 8b 07                mov    (%rdi),%rax
   3:   c6 40 02 09             movb   $0x9,0x2(%rax)
   7:   48 8b 07                mov    (%rdi),%rax
   a:   c6 40 02 0a             movb   $0xa,0x2(%rax)
   e:   c3                      retq   

=========== Expected results:

I expected the second redundant load to be eliminated - for example, clang
produces this assembler (after replacing the gcc specific uint8_t typedefs with
an include of <stdint.h>):

$ clang -Wall -O2 u8alias.c -c
$ objdump -ldr u8alias.o

0000000000000000 <f1>:
f1():
   0:   48 8b 07                mov    (%rdi),%rax
   3:   c6 40 02 0a             movb   $0xa,0x2(%rax)
   7:   c3                      retq   

=========== Other notes:

If the code is changed so that there are two redundant writes to ->f1 then gcc
does properly optimize away the first store.  Also, if the above definition of
f2 is changed to an 8-bit bitfield (ie, "uint8_t f2 : 8;") then gcc does
properly optimize away the first store.

This occurs on other platforms besides x86_64.  (In particular, it happens on
avr-gcc where 8-bit integers are very common.)  I reproduced the above on gcc
5.1.0, but I've also seen it on variants of gcc 4.8 and gcc 4.9.

My guess is that the above is the result of an interpretation of the C99
specification - in particular section 6.5:

  An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
[...]
      -- a character type.

However, I do not think that should apply to the above test case for either of
the two following reasons:

1 - the memory access was not to a character type, it was to an integer type
that happened to be 1 byte in size (ie, a uint8_t type)
2 - the memory access was not to a character type, it was to a member of
'struct s1'.

As noted above, clang (eg, 3.4.2) does perform the expected optimization.

[Bug tree-optimization/66110] uint8_t memory access not optimized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Uint8_t is a typedef by the c standard. And we typedef it to unsigned char
which means this is a character type.

[Bug tree-optimization/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

Kevin OConnor <kevin at koconnor dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED

--- Comment #2 from Kevin OConnor <kevin at koconnor dot net> ---
I understand that it is not incorrect to produce two redundant stores with the
sample code.  However, I do believe it would be correct to produce a single
store.

As such, I think this is an opportunity to improve gcc's optimization.  That
is, I think gcc could validly interpret the C spec so that two redundant
uint8_t stores could be replaced with one.

If this is not the best place to discuss that, what would be the best forum?

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, it for example breaks bootstrap via (broken...) -Wstrict-aliasing:

In file included from
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid/decimal128Local.h:1:0,
                 from /space/rguenther/src/svn/trunk/gcc/dfp.c:43:
/space/rguenther/src/svn/trunk/gcc/dfp.c: In function ‘bool
decimal_real_arithmetic(real_value*, tree_code, const real_value*, const
real_value*)’:
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:40:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] ^= 0x80; }
        ^
/space/rguenther/src/svn/trunk/gcc/dfp.c:704:2: note: in expansion of macro
‘decimal128FlipSign’
  decimal128FlipSign ((decimal128 *) r->sig);
  ^
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:36:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] &= ~0x80; }
        ^
/space/rguenther/src/svn/trunk/gcc/dfp.c:714:2: note: in expansion of macro
‘decimal128ClearSign’
  decimal128ClearSign ((decimal128 *) r->sig);
  ^
/space/rguenther/src/svn/trunk/gcc/dfp.c: In function ‘void
decimal_real_maxval(real_value*, int, machine_mode)’:
/space/rguenther/src/svn/trunk/gcc/../libdecnumber/dpd/decimal128Local.h:32:8:
error: dereferencing type-punned pointer will break strict-aliasing rules
[-Werror=strict-aliasing]
   { (d)->bytes[WORDS_BIGENDIAN ? 0 : 15] |= ((unsigned) (b) << 7); }
        ^
/space/rguenther/src/svn/trunk/gcc/dfp.c:754:5: note: in expansion of macro
‘decimal128SetSign’
     decimal128SetSign ((decimal128 *) r->sig, 1);
     ^
cc1plus: all warnings being treated as errors
make[3]: *** [dfp.o] Error 1


I remember dfp.c _does_ violate strict-aliasing.  Trying --disable-werror.
>From gcc-bugs-return-486071-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 12 09:20:08 2015
Return-Path: <gcc-bugs-return-486071-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 37250 invoked by alias); 12 May 2015 09:20:07 -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 37148 invoked by uid 48); 12 May 2015 09:19:59 -0000
From: "vekumar at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66049] Few AArch64 extend and add with shift tests generates sub optimal code with trunk gcc 6.0.
Date: Tue, 12 May 2015 09:20: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: 6.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vekumar at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: vekumar at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66049-4-ZeGmy8lihc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66049-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66049-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-05/txt/msg00911.txt.bz2
Content-length: 520

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf049

--- Comment #4 from vekumar at gcc dot gnu.org ---
(In reply to ktkachov from comment #3)
> Venkat, are you planning to submit this patch to gcc-patches?
> Also, does this mean we can remove the patterns that do arith+shift using
> MULT rtxes? (like *adds_<optab><mode>_multp2)

Hi Kyrill,

Yes I am planing to submit the patch. But before that I need to test by putting
some assert and check if *adds_<optab><mode>_multp2 and similar patterns are
not used anymore.

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bootstrapped / tested on x86_64 with --disable-werror

Running target unix/
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

Running target unix//-m32
FAIL: gcc.dg/alias-2.c  (test for warnings, line 14)
FAIL: gcc.dg/alias-2.c (test for excess errors)

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk.

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Wed May 13 10:53:42 2015
New Revision: 223126

URL: https://gcc.gnu.org/viewcvs?rev=223126&root=gcc&view=rev
Log:
2015-05-13  Richard Biener  <rguenther@suse.de>

        PR middle-end/66110
        * alias.c (alias_sets_conflict_p): Do not treat has_zero_child
        specially.
        * Makefile.in (dfp.o-warn): Add -Wno-strict-aliasing.

        * gcc.dg/alias-2.c: Adjust.
        * gcc.dg/tree-ssa/ssa-dse-17.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-17.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/Makefile.in
    trunk/gcc/alias.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/alias-2.c

[Bug middle-end/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

--- Comment #8 from Kevin OConnor <kevin at koconnor dot net> ---
Thanks!  I can confirm the latest trunk performs the desired optimization.

However, this test case still isn't fully optimized:

void f2(struct s1 *ps1, uint8_t *pi8)
{
    ps1->f1 = 3;
    *pi8 = 8;
    ps1->f1 += 2;
}

That is, an "uint8_t*" still aliases with every other type. The "struct"
optimization is more important for my usage, but it is unfortunate that
uint8_t*/int8_t* are pessimized.  (In particular, there does not appear to be
any way to declare a pointer to an 8 bit integer that doesn't alias every other
type.)

I can open a separate bugzilla entry on the above.

[Bug middle-end/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

--- Comment #10 from Kevin OConnor <kevin at koconnor dot net> ---
I've looked through the C specs (both C99 and C11) and I don't see anything
that requires uint8_t (nor int8_t) to be considered "character types".  I do
see three relevant sections in the spec which I'm including below.

For aliasing there is section 6.5:

  7 An object shall have its stored value accessed only by an lvalue expression
that has one of the following types:
  [...]
      -- a character type.

For "character types" there is section 6.2.5:

  15 The three types char, signed char, and unsigned char are collectively
called the character types. [...]

For uint8_t there is section 7.20.1.1:

     7.20.1.1 Exact-width integer types

  1 The typedef name intN_t designates a signed integer type with width N , no
padding bits, and a two's complement representation. Thus, int8_t denotes such
a signed integer type with a width of exactly 8 bits.

  2 The typedef name uintN_t designates an unsigned integer type with width N
and no padding bits. Thus, uint24_t denotes such an unsigned integer type with
a width of exactly 24 bits.

So, my read is that uint8_t must be considered an integer type, but is not
required to be considered a "character type".

That said, I understand that changing uint8_t may cause problems for some
existing user-code.  I'd think those enabling -fstrict-aliasing would want the
optimization benefit though.

I certainly understand if the cost of introducing another integer type and the
potential cost of causing issues for existing code is considered too high.  It
is unfortunate, though, that there doesn't appear to currently be any way to
declare a pointer to a non-aliasing 8-bit integer (that doesn't involve
'struct' hacks).

[Bug middle-end/66110] uint8_t memory access not optimized

[schwab@linux-m68k.org]

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

--- Comment #11 from Andreas Schwab <schwab@linux-m68k.org> ---
Since typedef does not create a new type the effect of uint8_t is exactly the
same as the type it is defined from.  Thus if uint8_t is defined from unsigned
char then uint8_t is a character type.

[Bug middle-end/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

--- Comment #12 from Kevin OConnor <kevin at koconnor dot net> ---
(In reply to Andreas Schwab from comment #11)
> Since typedef does not create a new type the effect of uint8_t is exactly
> the same as the type it is defined from.  Thus if uint8_t is defined from
> unsigned char then uint8_t is a character type.

Yes, of course.  My point is that gcc does not need to define uint8_t /
__UINT8_TYPE__ as 'unsigned char'.  Instead it could define it as a new integer
type (eg, __gcc_uint8_t) that is an 8-bit integer that does not alias.

As before, I understand if the cost of doing this is too high, but it's
unfortunate that there currently does not appear to be any way to define a
pointer to an 8-bit integer that doesn't alias.

[Bug middle-end/66110] uint8_t memory access not optimized

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I concur that it would be valid to define those typedefs to be extended 
integer types withing the special aliasing properties.  The first 
suggestion of that on the GCC lists that I know of is 
<https://gcc.gnu.org/ml/gcc/2000-05/msg01106.html>.  However, it was noted 
in <https://gcc.gnu.org/ml/gcc/2000-07/msg00155.html> that there would be 
C++ issues.  I see that C++ does now have extended integer types, which it 
didn't at that time, but there would still be questions of mangling 
(changing typedefs from standard headers breaks the library ABI for 
anything using those types in C++ interfaces, because of changed 
mangling).  And of course the question of what expectations might be 
broken in C by making these typedefs into extended integer types.

Cf <https://gcc.gnu.org/ml/gcc-patches/2002-01/msg01941.html> implementing 
a char_no_alias_everything attribute.

[Bug middle-end/66110] uint8_t memory access not optimized

[kevin at koconnor dot net]

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

--- Comment #14 from Kevin OConnor <kevin at koconnor dot net> ---
(In reply to joseph@codesourcery.com from comment #13)
> I concur that it would be valid to define those typedefs to be extended 
> integer types withing the special aliasing properties.  The first 
> suggestion of that on the GCC lists that I know of is 
> <https://gcc.gnu.org/ml/gcc/2000-05/msg01106.html>.  However, it was noted 
> in <https://gcc.gnu.org/ml/gcc/2000-07/msg00155.html> that there would be 
> C++ issues.  I see that C++ does now have extended integer types, which it 
> didn't at that time, but there would still be questions of mangling 
> (changing typedefs from standard headers breaks the library ABI for 
> anything using those types in C++ interfaces, because of changed 
> mangling).  And of course the question of what expectations might be 
> broken in C by making these typedefs into extended integer types.

Many thanks.  Those links and the background information is quite helpful.  I
agree that breaking the C++ ABI would not make sense on the major platforms.

> Cf <https://gcc.gnu.org/ml/gcc-patches/2002-01/msg01941.html> implementing 
> a char_no_alias_everything attribute.

I do think having something like "char_no_alias_everything" would be useful. 
My interest in this discussion was due to the code generation on the embedded
AVR platform (where 8-bit integers are very common).  If non-aliasing 8-bit
integer types existed, I suspect dealing with ABI breakage would be more
tenable on AVR.  (And if nothing else, utilizing them within an individual AVR
project would not be difficult.)

[Bug middle-end/66110] uint8_t memory access not optimized

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 18 May 2015, kevin at koconnor dot net wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66110
> 
> --- Comment #12 from Kevin OConnor <kevin at koconnor dot net> ---
> (In reply to Andreas Schwab from comment #11)
> > Since typedef does not create a new type the effect of uint8_t is exactly
> > the same as the type it is defined from.  Thus if uint8_t is defined from
> > unsigned char then uint8_t is a character type.
> 
> Yes, of course.  My point is that gcc does not need to define uint8_t /
> __UINT8_TYPE__ as 'unsigned char'.  Instead it could define it as a new integer
> type (eg, __gcc_uint8_t) that is an 8-bit integer that does not alias.

Yes, agreed.  Like {signed,unsigned,} __gcc_int8_t or so...

> As before, I understand if the cost of doing this is too high, but it's
> unfortunate that there currently does not appear to be any way to define a
> pointer to an 8-bit integer that doesn't alias.

Another possibility would be to introduce an attribute similar to
may_alias, "not_alias" so you can do

typedef unsigned char uint8_t __attribute__((no_alias));

or sth like that.  As that wouldn't alias with

typedef unsigned char my_uint8_t __attribute__((no_alias));

the effects might be surprising though.