Re: char and strict aliasing
On Jul 17, 10:10 pm, Paul Brettschneider
<paul.brettschnei...@yahoo.fr> wrote:
consider the following code:
typedef char T;
class test {
T *data;
public:
void f(T, T, T);
void f2(T, T, T);
};
void test::f(T a, T b, T c)
{
data[3] = a;
data[4] = b;
data[5] = c;
}
void test::f2(T a, T b, T c)
{
T *d = data;
d[3] = a;
d[4] = b;
d[5] = c;
}
g++ (v4.3, options "-fomit-frame-pointer -O3 -S -Wall") for x86 produces =
the
following nice code for f2:
movq (%rdi), %rax
movb %sil, 3(%rax)
movb %dl, 4(%rax)
movb %cl, 5(%rax)
ret
but quite strange code for f:
movq (%rdi), %rax
movb %sil, 3(%rax)
movq (%rdi), %rax
movb %dl, 4(%rax)
movq (%rdi), %rax
movb %cl, 5(%rax)
ret
Apparently the pointer data is reloaded after every store. I
guess this is due to the aliasing rules for char types: for
some strange reason data might point to itself and to be
correct it has to be reloaded after every store.
Indeed replacing the char for an int gives the same code for f
and f2. IMO this is a bad language decision: It's highly
inconsistent.
It's a pragmatic compromise. Low level software (think of the
implementation of memcpy or a garbage collector) must be able to
access the raw memory underlying the objects; at this level, the
compiler really should consider all pointers as possible aliases
to anything. Optimization needs require aliasing to be
restricted as much as possible, and in application code, of
course, there should pratically never be any such aliasing. The
C++ solution (inherited from C) is to allow char* and unsigned
char* (in C, only unsigned char*, I think) to alias anything,
since that covers most of the low level needs, and to restrict
the aliasing for other types. In practice, even this turned out
to be insufficient for optimization purposes, and C99 introduced
restrict.
Normally, I would expect a compiler to offer options to control
this: one to request it to ignore the types in possible aliasing
analysis (because there is code around which counts on e.g.
looking at a double through an unsigned short*), and another to
state that even char* won't alias another type (which is
non-conform, but if you don't need the feature). If the first
is missing, the compiler is pratically unusable for certain low
level tasks (although in general, it suffices to turn
optimization off); the latter is probably less important, but it
would help you here.
Anyway, having to live with it, I have to wonder how to
implement a char type which does not alias with everything.
struct MyChar { char ch ; } ;
A bit more awkward to use, but a MyChar* can only access a
MyChar.
Besides "char" I tried "unsigned char", "signed char",
"uint8_t" and "int8_t", all to no avail.
Well, uint8_t and int8_t are only typedef's. And in C++, I'm
not sure it's clear whether signed char is required or not, but
char and unsigned char certainly are. (Again, it's a
compromise. For the intended purpose, char and signed char
aren't usable in portable code. But most code doesn't have to
be that portable; in fact, most such low level code isn't, by
its very nature, portable. And correct or not, the use of char
for this is widespread, historically.)
Also the restrict keyword didn't help: g++
doesn't like it.
It's not legal C++. I would expect most C++ compilers to
support it, however, but only as an extension. So you'd loose
it if you turn extensions off (-std=c++98 or -ansi with g++). I
thought that this was the case with g++, but I've never had the
occasion to verify it.
As a last measure I tried a wrapper class:
typedef class my_char {
char data;
public:
my_char() { }
my_char(char c) { data = c; }
char operator=(char c) { return data = c; }
char operator=(my_char c) { return data = c.data; }
operator char() { return data; }
} T;
Amazingly, this produces byte by byte the same code as using a
simple char. g++ cannot be right about this one: Does "class
{ char x; }" really have the same aliasing rules as "char"?
You'd have to show us the actual code you used. my_char* cannot
be used to access a pointer, so it should work.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34