Skip to content
This repository was archived by the owner on Feb 13, 2025. It is now read-only.

Replace goobledigoobs trick with consistent and future-proof assembly. #163

Closed

Conversation

matthewaveryusa
Copy link

the goobledigoobs trick has been and will always be an optimization target for compilers. In fact it no longer works for gcc 5.4. The only way to consistently have the alloca not optimized out is to issue assembly that reads from the pointer and instructs that a read/write may occur anywhere in memory.

A little more work needs to be done to make this cross-platform -- perhaps a macro for the various platforms that clobbers a pointer. Facebook folly has such a wrapper here:
https://github.com/facebook/folly/blob/master/folly/Benchmark.h

@akruis
Copy link

akruis commented Jul 17, 2018

There is another similar trick in

char _dont_optimise_away_slp_eval_frame_functions;

Writing to a global variable is only safe, if you don't use link time optimisation. Therefore we really should change the code. But it needs to to be done in a more portable way. We need to support at least gcc, clang and VisualStudio.

@kristjanvalur
Copy link
Collaborator

I should add that all of this went away in the experimental stackless version that used the "tealet" switching code.
see https://bitbucket.org/krisvale/stackless-tealet
https://bitbucket.org/krisvale/tealet

@ctismer
Copy link
Collaborator

ctismer commented Nov 11, 2018

@kristjanvalur hey, you are right! The switching version that Armin implemented was a bit more intelligent than my code and did not need such tricks. Maybe we should adopt this instead of employing more assembly?

@akruis
Copy link

akruis commented Nov 11, 2018

Obsoleted by issue #181.

@akruis akruis closed this Nov 11, 2018
@kristjanvalur
Copy link
Collaborator

@kristjanvalur hey, you are right! The switching version that Armin implemented was a bit more intelligent than my code and did not need such tricks. Maybe we should adopt this instead of employing more assembly?

Well, it would have the benefit of sharing the switching code with the greenlet code, which is actively maintained. And the dynamic stack climbing code that armin wrote originally and I then worked on is pretty clever.

Another upside is to be able to abstract stack-slicing away into a separate library all together, which cleans up things very much.

The downside is that it is quite a radical change. I think I tried to document the changes I made in the repository branch, step by step, to explain them.

@akruis
Copy link

akruis commented Nov 13, 2018

@kristjanvalur and @ctismer : let's continue the discussion in issue #10.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants