Currently Parrot is picking up Perl's C compiler flags. Perl is quite
deliberately attempting to set -fno-strict-aliasing, to stop gcc using
ANSI's aliasing rules to infer possible optimisations; optimisations that
will actually break Perl's code.
(Don't ask me to remember exactly what the aliasing rules are, let alone
explain them correctly, but it's something to do with more than one type of
pointer not being allowed to point at the same thing (except via a union,
and where char pointers are exempt) in a strictly conformant ANSI C
program. Providing this holds true in the C source, the compiler can safely
reorder memory access and potentially gain speedups. Perl's source isn't
ANSI conformant in this way. Well, you can ask what the aliasing rules are,
but I won't answer)
The upshot is that you can't guarantee that any compiler won't be optimising
based on aliasing assumptions, because, hell, it's allowed to. And we may
not be able to turn it off. So we ought to be writing code that doesn't make
aliasing assumptions. Hence we ought to remove -fno-strict-aliasing from
Parrot's cflags. And as Dan put it "see what breaks". So far nothing, at
least for a test build on Debian/x86. And as we're now letting gcc make
aliasing based optimisations, we might see more speed. (And maybe unicorns,
flying pigs, and round tuits)
Nicholas Clark
--- config/inter/progs.pl~ Fri Oct 25 11:23:17 2002
+++ config/inter/progs.pl Tue Dec 31 21:18:24 2002
@@ -15,6 +15,7 @@ sub runstep {
my($cc, $link, $ld, $ccflags, $linkflags, $ldflags, $libs) =
Configure::Data->get(qw(cc link ld ccflags linkflags ldflags libs));
$ccflags =~ s/-D(PERL|HAVE)_\w+\s*//g;
+ $ccflags =~ s/-fno-strict-aliasing//g;
$linkflags =~ s/-libpath:\S+//g;
$ldflags =~ s/-libpath:\S+//g;
my $debug='n';
