Re: char and strict aliasing
Hello Alexandre and James, thanks for your reply!
James Kanze wrote:
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.
I understand that. But I would expect programmers of low level code like
garbage collectors to understand aliasing and be able to explicitly tell
the compiler when aliasing is possible. Of course some old weird code might
break. OTOH C++ breaks old C code anyway...
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).
Exactly.
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.
My editor recognises it as reserved word, but g++ doesn't like it - at least
not without some command line argument.
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.
Exactly the same code as above, but with the other typedef:
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;
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;
}
Gives byte by byte the same code as with "typedef char T;". Of course I'm
not sure that you can call this a bug since after all the code is correct,
it's just not as efficient as it could be. Using stronger aliasing rules
you're always on the safe side. Still it makes me wonder where the aliasing
rules are implemented in g++? You can even change the wrapper class to
(note the negations):
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;
and get the following code:
f:
movq (%rdi), %rax
negl %esi
negl %edx
negl %ecx
movb %sil, 3(%rax)
movq (%rdi), %rax #!!
movb %dl, 4(%rax)
movq (%rdi), %rax #!!
movb %cl, 5(%rax)
ret
f2:
movq (%rdi), %rax
negl %esi
negl %edx
negl %ecx
movb %sil, 3(%rax)
movb %dl, 4(%rax)
movb %cl, 5(%rax)
ret
So g++ apparently assumes that my_char*, a class that shows completely
different behaviour than char, can point to a "class test").
But I guess this starts to be highly compiler specific and is offtopic
here...