headers
Ivan Maidanski | 2 Aug 2012 00:10
Picon

Re[7]: [Gc] cc under mac os x

Hi Hans and Daniel,

You're right.
Done another commit (a group of). Please check it once more.

I finally realized that GC_approx_sp not only clarifies but also fixes (this is not related to compiler
optimizations) the algorithm of GC_clear_stack_inner for STACK_GROWS_UP case.

Regards,
Ivan

Wed, 1 Aug 2012 17:12:23 +0000 "Boehm, Hans" <hans.boehm@...>:
> Ivan -
> 
> 
> 
> Since it's the address, and not the value of dummy that's used, I wouldn't have expected that to have any
impact.  I think that switching to GC_approx_sp() clarifies the code and avoids the problem.  It does so at a
tiny performance cost, but I doubt that's ever noticeable.
> 
> 
> 
> I didn't look carefully at the other changes, but I think they have similar issues.  I don't see how volatile
helps either.  The problem here is that I think C officially disallows comparisons of pointers to
different objects.  Hence GC_clear_stack() doesn't play by the rules.  But so long as the compiler doesn't
know where the pointers are coming from, it has to generate the expected code, and things will work.
> 
> 
> 
> An alternative would be to write more of this in assembly code, but that's a pain to maintain.
(Continue reading)

Permalink | Reply |
headers
Grayson, Daniel R. | 2 Aug 2012 00:24
Picon
Favicon
Gravatar

Re: cc under mac os x

That worked for clang.

But what about undoing the commit that inserted all the "volatile" attributes?
For clarity.

On Aug 1, 2012, at 6:10 PM, Ivan Maidanski <ivmai@...> wrote:

> Hi Hans and Daniel,
> 
> You're right.
> Done another commit (a group of). Please check it once more.
> 
> I finally realized that GC_approx_sp not only clarifies but also fixes (this is not related to compiler
optimizations) the algorithm of GC_clear_stack_inner for STACK_GROWS_UP case.
> 
> Regards,
> Ivan
> 
> Wed, 1 Aug 2012 17:12:23 +0000 "Boehm, Hans" <hans.boehm@...>:
>> Ivan -
>> 
>> 
>> 
>> Since it's the address, and not the value of dummy that's used, I wouldn't have expected that to have any
impact.  I think that switching to GC_approx_sp() clarifies the code and avoids the problem.  It does so at a
tiny performance cost, but I doubt that's ever noticeable.
>> 
>> 
>> 
>> I didn't look carefully at the other changes, but I think they have similar issues.  I don't see how
(Continue reading)

Permalink | Reply |
headers
Ivan Maidanski | 2 Aug 2012 12:48
Picon

Re[9]: [Gc] cc under mac os x

Hi Daniel,

1. I removed almost dummy variables (together with volatile, of course).
2. For clarity (and to prevent potential compiler optimizations), volatile should remain.
3. I'm not going to prepare a cumulative patch, if you need to fix some other BDWGC source, just apply these 3
patches (not sure that they can be applied to gc7.3alpha2 smoothly):
https://github.com/ivmai/bdwgc/commit/d6acbda22a4f5bdf4340edacdccf01cc7e38aea8
https://github.com/ivmai/bdwgc/commit/57b94a38df8026868010ec2ea0f47cd1f94f0c60
https://github.com/ivmai/bdwgc/commit/f1f2d378a04ac3f1be330ea6df6e553295657e22

4. I've applied the patches to release-7_2 candidate branch as well, please test it: https://github.com/ivmai/bdwgc/tree/gc-7_2-hotfix-3

Regards,
Ivan

Wed, 1 Aug 2012 18:24:25 -0400 "Grayson, Daniel R." <dan@...>:
> That worked for clang.
> 
> But what about undoing the commit that inserted all the "volatile" attributes?
> For clarity.
> 
> On Aug 1, 2012, at 6:10 PM, Ivan Maidanski <ivmai@...> wrote:
> 
> > Hi Hans and Daniel,
> > 
> > You're right.
> > Done another commit (a group of). Please check it once more.
> > 
> > I finally realized that GC_approx_sp not only clarifies but also fixes (this is not related to compiler
optimizations) the algorithm of GC_clear_stack_inner for STACK_GROWS_UP case.
(Continue reading)

Permalink | Reply |
headers
Grayson, Daniel R. | 2 Aug 2012 13:48
Picon
Favicon
Gravatar

Re: cc under mac os x

Okay, the latest branch still works with clang, and so does

	gc-7_2-hotfix-3

But I don't see how "volatile" in the line

	volatile word dummy[CLEAR_SIZE]; 

adds any clarity.  It's confusing, because dummy refers
to an ordinary memory location, not an I/O port or a register, and
we aren't worried about interference from other threads.  The only
access to dummy is through BZERO, so there is no apparent compiler
optimization to be feared.

On Aug 2, 2012, at 6:48 AM, Ivan Maidanski <ivmai@...> wrote:

> Hi Daniel,
> 
> 1. I removed almost dummy variables (together with volatile, of course).
> 2. For clarity (and to prevent potential compiler optimizations), volatile should remain.
> 3. I'm not going to prepare a cumulative patch, if you need to fix some other BDWGC source, just apply these 3
patches (not sure that they can be applied to gc7.3alpha2 smoothly):
> https://github.com/ivmai/bdwgc/commit/d6acbda22a4f5bdf4340edacdccf01cc7e38aea8
> https://github.com/ivmai/bdwgc/commit/57b94a38df8026868010ec2ea0f47cd1f94f0c60
> https://github.com/ivmai/bdwgc/commit/f1f2d378a04ac3f1be330ea6df6e553295657e22
> 
> 4. I've applied the patches to release-7_2 candidate branch as well, please test it: https://github.com/ivmai/bdwgc/tree/gc-7_2-hotfix-3
> 
> Regards,
> Ivan
(Continue reading)

Permalink | Reply |
headers
Ivan Maidanski | 2 Aug 2012 14:04
Picon

Re[11]: [Gc] cc under mac os x

Hi Daniel,

Thu, 2 Aug 2012 07:48:38 -0400 "Grayson, Daniel R." <dan@...>:
> Okay, the latest branch still works with clang, and so does
> 
> 	gc-7_2-hotfix-3
> 
> But I don't see how "volatile" in the line
> 
> 	volatile word dummy[CLEAR_SIZE]; 
> 
> adds any clarity.  It's confusing, because dummy refers
> to an ordinary memory location, not an I/O port or a register, and
> we aren't worried about interference from other threads.  The only
> access to dummy is through BZERO, so there is no apparent compiler
> optimization to be feared.

BZERO could be redirected to builtin_memset thus the code:

word dummy[SIZE];
BZERO(dummy, sizeof(dummy));

could turn into:

dummy[0] = 0;
...
dummy[SIZE-1] = 0;

and, since there is no readers of dummy, it is a dead code and code be wiped out.
(Continue reading)

Permalink | Reply |
headers
Grayson, Daniel R. | 2 Aug 2012 17:00
Picon
Favicon
Gravatar

Re: cc under mac os x

Good point!  I didn't think of that optimization.

On Aug 2, 2012, at 8:04 AM, Ivan Maidanski <ivmai@...> wrote:

> Hi Daniel,
> 
> Thu, 2 Aug 2012 07:48:38 -0400 "Grayson, Daniel R." <dan@...>:
>> Okay, the latest branch still works with clang, and so does
>> 
>> 	gc-7_2-hotfix-3
>> 
>> But I don't see how "volatile" in the line
>> 
>> 	volatile word dummy[CLEAR_SIZE]; 
>> 
>> adds any clarity.  It's confusing, because dummy refers
>> to an ordinary memory location, not an I/O port or a register, and
>> we aren't worried about interference from other threads.  The only
>> access to dummy is through BZERO, so there is no apparent compiler
>> optimization to be feared.
> 
> BZERO could be redirected to builtin_memset thus the code:
> 
> word dummy[SIZE];
> BZERO(dummy, sizeof(dummy));
> 
> could turn into:
> 
> dummy[0] = 0;
> ...
(Continue reading)

Permalink | Reply |

Gmane