-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: rebase to llvm head #917
Open
undingen
wants to merge
3,173
commits into
pyston:master
Choose a base branch
from
undingen:llvm_upgrade2
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rewrite float comparison base on CPython implementation
NumPy is huge, bigger than our previous (arbitrary) number by an order of magnitude.
C extensions (NumPy) might inherit classes in C code and expect to find tp_number. This is just copied from CPython's PyType_Ready. This requires assigning some of the runtime functions to thesq_ and mp_ slots otherwise there are infinite loops from Pyston attributes.
Those should never exist because all Python objects should be created through the CPython API except for type objects. Unfortunately, some places like NumPy do that so we need a mean of patching it for now.
…bjects. Instead of GCKind::HIDDEN_CLASS, use GCKind::RUNTIME and require that the runtime objects have a gc_visit functions by inheriting from GCAllocatedRuntime.
Refactors on types of GC objects
Previously, we would just call these "conservative python" objects, and scan their memory conservatively. The problem with this is that the builtin type might have defined a custom GC handler that needs to be called in addition to the conservative scanning (ie it stores GC pointers out-of-band that are not discoverable via other gc pointers). We had dealt with these kinds of issues before which is why I added the "conservative python kind", but I think the real solution here is to say that to the GC, these objects are just python objects, and then let the type machinery decide how to scan the objects, including how to handle the inheritance rules. We were already putting "conservativeGCHandler" as the gc_handler on these conservative types, so let's use it.
Previously it would have to call out to checkAndThrowCAPIException(), which is quite a bit slower than what it now can do, which is directly checking the return value.
Get Pyston building on Fedora
Improve dictionary performance
Some work on the NumPy test
More small optimizations
First job: check for cases where we call isSubclass() when it would be faster to call Py*_Check Probably overkill for this. Pretty cool though that it found a case that would have been impossible to spot textually, where there was an implicit this-> member access.
ie everything that the linter was warning about
This will reallocate all objects in the small heap and update all references that were pointing to this object. This is not functional yet, there are still references that we are not tracking at other points in the program, so it's still gated behind the MOVING_GC flag.
Last few fixes to make sqlalchemy_declarative work
Optionally move objects around in memory to prepare Pyston for a moving collector.
rewrite oldstyle class getattro
ie concerning things like: a, b = 1, 2 The irgen phase already knows how to do unpacking in a type-analyzed way (a and b will be of type int), but type speculation needed to have that added.
Used a hardcoded CXX exception style in the non-rewriteable case.
Type system fix: need to add unpacking to the type system
…CPython with some Pyston changes
PrintVisitor: use raw_ostream
Implment some PyNumber_XXX function, to enable "test_operator"
We already supported changing the values, but not the number of them. The main trickiness here is - We had been assuming that the number of defaults was immutable, so I had to find the places that we used it and add invalidation. - We assumed that all functions based on the same source function would have the same number of defaults. For the first one, I found all the places that looked at the defaults array, which should hopefully be all the places that need invalidation. One tricky part is that we will embed the num_defaults data into code produced by the LLVM tier, and we currently don't have any mechanism for invalidating those functions. This commit side-steps around that since the only functions that we can inline are the builtins, and those you aren't allowed to change the defaults anyway. So I added a "can_change_defaults" flag. For the second part, I moved "num_defaults" from the CLFunction (our "code" object) to the BoxedFunction (our "function" object), and then changed the users to pull it from there.
Allow changing the number of default arguments
Fix set comparisons
Add support for symbolic patchpoint targets to SelectionDAG and the X86 backend.
kmod
force-pushed
the
master
branch
2 times, most recently
from
October 28, 2020 21:01
352fd89
to
6488a3e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
there are still a few issues but I would like to to trigger a travis ci run.
Will update the PR when it's ready