Skip to content
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
wants to merge 3,173 commits into
base: master
Choose a base branch
from
Open

WIP: rebase to llvm head #917

wants to merge 3,173 commits into from

Conversation

undingen
Copy link
Contributor

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

kmod and others added 30 commits August 11, 2015 01:03
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.
Improve dictionary performance
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
rudi-c and others added 27 commits September 4, 2015 15:10
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.
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
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
Add support for symbolic patchpoint targets to SelectionDAG and the
X86 backend.
@kmod kmod added the wip label Sep 14, 2015
@kmod kmod force-pushed the master branch 2 times, most recently from 352fd89 to 6488a3e Compare October 28, 2020 21:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants