code review 73830044: runtime: use unoptimized memmove and memclr on Plan 9

runtime: use unoptimized memmove and memclr on Plan 9

On Plan 9, the kernel disallows the use of floating point
instructions while handling a note. Previously, we worked
around this by using a simple loop in place of memmove.

When I added that work-around, I verified that all paths
from the note handler didn't end up calling memmove. Now
that memclr is using SSE instructions, the same process
will have to be done again.

Instead of doing that, however, this CL just punts and
uses unoptimized functions everywhere on Plan 9.

[ality, 2014-03-12 12:12:25]

Hello rsc@golang.org, 0intro@gmail.com (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[ality, 2014-03-12 12:39:37]

The alternative to this is making the note handler a really
small trampoline into runtime·sigpanic and a new function,
runtime·sigthrow. I could do it that way if you prefer to
have memmove and memclr the same on all platforms.

  Anthony

[rsc, 2014-03-12 15:51:47]

LGTM

I'm not thrilled but it's fine.

[0intro, 2014-03-12 18:57:20]

It looks fine to me.

[ality, 2014-03-13 01:12:49]

*** Submitted as https://code.google.com/p/go/source/detail?r=3018a8137880 ***

runtime: use unoptimized memmove and memclr on Plan 9

On Plan 9, the kernel disallows the use of floating point
instructions while handling a note. Previously, we worked
around this by using a simple loop in place of memmove.

When I added that work-around, I verified that all paths
from the note handler didn't end up calling memmove. Now
that memclr is using SSE instructions, the same process
will have to be done again.

Instead of doing that, however, this CL just punts and
uses unoptimized functions everywhere on Plan 9.

LGTM=rsc
R=rsc, 0intro
CC=golang-codereviews
https://codereview.appspot.com/73830044