Re: PATCH: arm*-*-symbianelf* configuration

[Roger Sayle <roger at eyesopen dot com>]

Hi Mark,

On Tue, 3 Aug 2004, Mark Mitchell wrote:
> + /* Do not expand builtin functions (unless explicitly prefixed with
> +    "__builtin").  Symbian OS code relies on properties of the standard
> +    library that go beyond those guaranteed by the ANSI/ISO standard.
> +    For example, "memcpy" works even with overlapping memory, like
> +    "memmove".  We cannot simply set flag_no_builtin in arm.c because
> +    (a) flag_no_builtin is not declared in language-independent code,
> +    and (b) that would prevent users from explicitly overriding the
> +    default with -fno-builtin, which may sometimes be useful.
> + #define CC1_SPEC "-fno-builtin -fvisibility=hidden"
> + #define CC1PLUS_SPEC "-fno-builtin -fvisibility=hidden"

I think this is a reasonable first approximation to solving your problem.

In the longer term, however, I believe the performance penalty of
disabling all 450+ of GCC's builtin intrinsics might be a severe
handicap for using GCC on Symbian OS.  I'd suspect that perhaps there
may be, at most, ten or so problematic functions that require modified
semantics, so it would be preferable to list these individually in the
above SPECs, for example, "-fno-builtin-memcpy -fno-builtin-foo" etc...

Consider your new gcc.dg/symbian2.c test case for example:

+ /* { dg-final { scan-assembler "strlen" } } */
+
+ int f() {
+   return strlen("abc");
+ }

Is there really any conceivable reason why GCC shouldn't be allowed to
optimize this to "return 3" at compile-time?  I'd be surprised if Symbian
OS semantics are *that* different.  Optimizations of "sqrt" and "ffs"
tend to help MP3 codecs and other software common in embedded devices.


Even longer term, it might be preferable to tackle the "memcpy" problem
within the new backend itself, for example by overriding the default
ARM backend value for MOVE_RATIO, and setting it to zero (or one?).
This should cause GCC to always generate calls to libc's memcpy rather
than attempt to implement it inline (with the more usual semantics).


Just my 2c.

Roger
--