On Sunday 31 March 2013 16:17:34 Jakub Jermar wrote: > Hi, > > let's discuss some of the possibilities to prevent the compiler from > optimizing our C implementation of mempcy()/memset() via a call to > memcpy()/memset(). > > I noticed Martin has already started to replace the C implementations > with implementations written in assembly. This will surely stop GCC from > creating this recursion, but is this the most elegant/maintainable thing > to do? > > I experimented a little bit and it seems that each of the following > works too: > > - making all pointers to the destination buffer in mempcy/memset > volatile > > - adding memcpy and memset __attribute__ ((optimize(2))) > > The benefit is that we don't have to provide a dozen of asm implementations. > > I also wonder whether we are not confusing gcc ourselves. On one had, we > build with -ffreestanding and -fno-builtin, but on the other hand we > define memcpy/memset as __builtin_memcpy/memset and provide our own > implementation. This looks like an open invitation for this recursion.
I guess the first thing we should do is to investigate the mechanism of the problem. And then if it's us misusing gcc we should fix it, otherwise we should file a bug. I don't think it's an urgent issue, so we shouldn't make any rapid moves to workaround it. I haven't had time to look at it, as I want to use my spare time now to finish Python port (or at least bring it to some publishable state, which hopefully will happen tomorrow), but when I'm done with it, I'm volunteering to investigate the issue in detail. Also is it about userland memcpy? If so I don't see it being defined in terms of __builtin_memcpy (just a quick grep, so I may be wrong). Cheers, Zbigniew Halas _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
