[linux-cirrus] Re: crunch tools update

On Thu, 4 Oct 2007 18:28:42 +0100, "Martin Guy" <martinwguy@xxxxxxxx>
said:
 
> We seem to be using two different sets of gcc patches for crunch
> support. From a quick inspection they have some things in common, but
> while these have 18 distinct crunch patch files for separate issues,
> cirrus-1.4.0 has a single 48kb file, which makes a point-by-point
> comparison of their features rather difficult.

I'm the one who wrote those patches. They are separate files since
merging them into mainline GCC will be simpler, if each issue is kept
separate.  Someone merged these into org.openembedded.dev tree without
letting me know.  These patches will break a heap of stuff for other ARM
processors, and that's why they've been taken out of the gcc-4.1.2
openembedded mainline tree [3].

Koen, please comment that the patches in the gcc-4.2.1 directory are
experimental at this stage.  These patches really should only been
enabled if you are building for "ep93xx".  They disable conditional
execution on the ARM for all ARM processors, so your code will be larger
than if you don't include these patches.

I don't suggest that anyone uses tune-ep9312.inc when compiling for
crunch, especially because of the problems mentioned below (esp glibc
libm problems).  We are still using tune-arm920t.inc, and adding the
following lines to bb files when I want MaverickCrunch instructions:

TARGET_CFLAGS_append_ep93xx = " -mcpu=ep9312 -mfpu=maverick
-mfloat-abi=softfp -D__MAVERICK__ "
TARGET_CXXFLAGS_append_ep93xx = " -mcpu=ep9312 -mfpu=maverick
-mfloat-abi=softfp -D__MAVERICK__ "

Also, I had a small patch to binutils, but I'm not 100% sure if this is
needed.

If/when I get round to updating my patches, can people please test this
stuff more fully before we commit them upstream?
 
> I've applied the new 1.4.0 set to a clean gcc-4.1.2 (plus
> unbreak-armv4t.patch) and run the gcc testsuite for ieee FP on them on
> EP93xx Maverick hardware.
> (Runes: in the gcc build dir: make check-gcc RUNTESTFLAGS="ieee.exp
> --target_board=unix/-mcpu=ep9312/-mfpu=maverick/-mfloat-abi=softfp")

This is the way to test it. :)  Of course it doesn't stress test it, and
doesn't cover the tests against the errata [1].  I'd appreciate it if
someone could help write some testcases (in C) to test for all the
maverick crunch errata errors.  We can then add them to the gcc dejagnu
tests.

> I'm sorry to have to report that gcc-4.1.2 with cirrus-1.4.0 patches
> fails many of the tests.
> It succeeds in compiling them but execution gives wrong results:
> # of expected passes            530
> # of unexpected failures        90

This automated testing is through dejagnu. 
http://lists.gnu.org/archive/html/dejagnu/2006-04/msg00008.html gives a
reasonable explanation on how to set it up.  I can go into more detail
if others are interested.  

> It's not all bad though - the few tiny test programs I have, that go
> crazy with standard gcc-4.1.2,
> do seem to work with the cirrus-1.4.0-patched gcc-4.1.2.

> The futaris patches for gcc-4.1.2 and gcc-4.2.0 both pass the ieee
> tests with 100% success.
> I suggest you investigate those. You'll find they share a lot in
> common with yours, such as the uclibc patches.

I have had some problems with E2 silicon and my patches, at -O0.  Do you
see these?

> The detailed cirrus-1.4.0 IEEE test results are visible at
> martinwguy.co.uk/martin/FPU/build-4.1.2-cirrus/gcc/testsuite/gcc/gcc.log
> (and similarly .../build-4.{1.2,2.0}-futaris/.../gcc.log)
> and the futaris patches for gcc-4.1.2 are unpacked under
> martinwguy.co.uk/martin/FPU/futaris//gcc/gcc-4.1.2
> (see the file "series" for which patches are to be used, generated by
> me from ../gcc_4.1.2.bb)

> The hardware I'm running them on is EP93xx chips with silicon revision
> E1 (at least, those are the 5th and 6th chars on the second line on
> the casing).
> Another EP93 system, which I can't currently use for Crunch testing,
> has revision E0.
> Do you know whether these correspond to crunch D0 and D1 or are they
> both post-D1?

This is also something I'm trying to chase up.  We have some E1 and E2
rev silicon.  But I'm not 100% sure of what Errata / bugs are in the
MaverickCrunch.  Our compiled code seems to run fine on rev E1, but not
rev E2.  I haven't narrowed down the cause of the problem yet.  As far
as I can tell each revision of silicon has a number of errata [1], but I
don't think any gcc patches have covered them all.  Ideally
TARGET_CIRRUS_D0, TARGET_CIRRUS_D1, etc shouldn't be set at compile time
but rather calculated at runtime, especially as the fixes vary for each
processor, and you don't want to have 4+ different versions of firmware
just for each different processor.

> In all cases I'm not using any fix-crunch-dx options.

That's not entirely true.  My patches HARD CODE fix-crunch-d1:

@@ -179,6 +182,9 @@
 #define TARGET_HARD_FLOAT_ABI           (arm_float_abi ==
 ARM_FLOAT_ABI_HARD)
 #define TARGET_FPA                      (arm_fp_model ==
 ARM_FP_MODEL_FPA)
 #define TARGET_MAVERICK                 (arm_fp_model ==
 ARM_FP_MODEL_MAVERICK)
+#define TARGET_CIRRUS                  (arm_arch_cirrus)
+#define TARGET_CIRRUS_D0               0 /* (target_flags &
ARM_FLAG_CIRRUS_D0) */
+#define TARGET_CIRRUS_D1               1 /* (target_flags &
ARM_FLAG_CIRRUS_D1) */
 #define TARGET_VFP                      (arm_fp_model ==
 ARM_FP_MODEL_VFP)
 #define TARGET_IWMMXT                   (arm_arch_iwmmxt)
 #define TARGET_REALLY_IWMMXT            (TARGET_IWMMXT && TARGET_ARM)

On another note, my patches don't work 100% yet.  The main issues (that
I remember at the moment) are:

a) Don't work with glibc libmath, etc.  tanh(double) fails.
b) I disable conditional execution.  See [2] for why.
c) I don't think I cover all the MaverickCrunch errata correctly.  I
think only MaverickCrunch erratum 1-4 from the Errata at [1] are
definitely covered.

NB, I haven't looked at whether the MaverickCrunch stuff is in
Serialized / Non-Serialized mode.

[1] http://www.cirrus.com/en/products/pro/detail/P131.html
[2] http://gcc.gnu.org/ml/gcc/2007-06/msg00903.html
[3]
http://lists.linuxtogo.org/pipermail/openembedded-devel/2007-August/002928.html

Other related posts: