Re: [Minios-devel] [PATCH ARM v9 1/3] mini-os: fix compiling with debug=n

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2015-06-25 at 18:03 +0100, Anil Madhavapeddy wrote:
> On 25 Jun 2015, at 16:49, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> > 
> > On Thu, 2015-06-25 at 14:48 +0100, Thomas Leonard wrote:
> >> Without -fno-tree-loop-distribute-patterns, gcc -O3 recognises that our
> >> "memset" is doing a memset operation and tries to make it call the
> >> standard "memset", creating a loop.
> > 
> > Isn't this what -nostdlib and such like are for?
> > 
> > In any case if we are to go down this route I think we'd be better off
> > applying it only to lib/string.c or even better just to the memset
> > function, if there is a way to do that.
> 
> I think -nostdlib is distinct from -fno-builtins.  If the issue is
> convincing GCC to not replace the memset with a builtin one, would
> -fno-builtin-memset be more appropriate here?

Assuming that's a thing then yes, a bunch of
-fno-builtin-<specific-thing-we-provide> would be better than
-fno-builtins would be better than -nostdlib would be better than a
bunch of -fno-foo-optimisation to stop gcc generating builtin calls.

I'd assume that memset is just the first thing we've found and that
there might be other cases, e.g. memcpy which just aren't seeing yet, in
which case we might need a broad set of -fno-builtin-foo

Ideally the tweak would be applied with the smallest possible scope,
such that when compiling application code gcc can spot memset
opportunities and call the "builtin" which is actually the one provided
by mini-os. If it's more complicated than
__attribute__((no-builtin-memset)) on the function then it's probably
not worth losing too much sleep over though.

Ian.


_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel