lwsync instruction doesn't exist on powerpc e500 core

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Compile for an e500 core and try to run on e500
2.
3.

What is the expected output? What do you see instead?
It will generate an illegal instruction exception on the lwsync

What version of the product are you using? On what operating system?
Version 1.2 on Linux 2.6.23

Please provide any additional information below.
The lwsync should be replaced with an msync if the processor is an e500.

Original issue reported on code.google.com by smoothop...@hotmail.com on 5 Jun 2009 at 7:15

[GoogleCodeExporter]

Hmm, I do't know how to test for e500 processor.  Can you supply a patch?

Is msync equivalent to lwsync, or are there differences we should be aware of?

Original comment by csilv...@gmail.com on 5 Jun 2009 at 7:18

• Changed state: Accepted

[GoogleCodeExporter]

Here's a patch for atomicops-internals-linuxppc.h.  

lwsync should be a subset of an msync.

Original comment by smoothop...@hotmail.com on 8 Jun 2009 at 3:03

Attachments:

• fsl_e500.patch

[GoogleCodeExporter]

Wow, gcc supports a macro for just this situation?  Makes life easier for us, 
that's
for sure!  The patch will be in the next perftools release, which should be 
sometime
this month.

Original comment by csilv...@gmail.com on 8 Jun 2009 at 6:46

• Changed state: Started

[GoogleCodeExporter]

Original comment by csilv...@gmail.com on 8 Jun 2009 at 7:57

• Added labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

I asked a local asm expert here, who had the following questions/concerns:
---
If you run gcc with default flags (not cross compiling) on a machine
that supports lwsync,
does gcc itself generate code that runs on all PPC machines?
And does it set __NO_LWSYNC__?
(If it does the former, but not the latter,  then this
change could be surprising to people hoping to generate generic binaries.)

What happens when "lwsync" is presented to gas when gcc has set __NO_LWSYNC__?
Does the assembler barf, or does it assemble correctly and fail at run time?

What is the performance penalty on a typical application of using
"msync" always?
(If low, we could just use "msync".)
---

I'm also worried about building a library that will run on all ppc systems (say 
if we
make a .deb or .rpm file).  Is that a legitimate worry?  What is the best way to
resolve all these issues?

I'm cc-ing Anton Blanchard, who provided the original patch for lwsync.  Anton, 
any
advice here?

Original comment by csilv...@gmail.com on 9 Jun 2009 at 10:04

[GoogleCodeExporter]

I've added the __NO_LWSYNC__ check in perftools 1.3, just released.  But I'm 
going to
leave this bug open a little longer until we figure out if this is a principled
solution, and/or if there's a better one.

Original comment by csilv...@gmail.com on 10 Jun 2009 at 2:06

[GoogleCodeExporter]

When lwsync is presented to gas when gcc has __NO_LWSYNC__ it assembles 
correctly 
and generates an illegal instruction at runtime.

"msync" may also not be portable across all powerpc systems since it is for 
e500. I 
think it would have to be a "sync" instead.  

I don't know how significant the performance impact between a "sync" and 
"lwsync" 
is.  If needed I can check with my contacts within Freescale for an answer.

Original comment by smoothop...@hotmail.com on 10 Jun 2009 at 1:27

[GoogleCodeExporter]

Feel free to.  My guess is sync is significantly slower than lwsync.  There may 
be no
great answer here; what's in perftools 1.3 may be the best we can do here.  But 
if
folks who know a lot about PPC have a better suggestion, I'm glad to consider 
it!

Original comment by csilv...@gmail.com on 10 Jun 2009 at 10:38

[GoogleCodeExporter]

This should be fixed in perftools 1.4, just released.

Original comment by csilv...@gmail.com on 11 Sep 2009 at 6:47

• Changed state: Fixed