- 11 Aug, 2015 7 commits
-
-
Rudi Chen authored
-
Rudi Chen authored
-
Rudi Chen authored
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.
-
Rudi Chen authored
NumPy is huge, bigger than our previous (arbitrary) number by an order of magnitude.
-
Rudi Chen authored
-
Kevin Modzelewski authored
rewrite float comparison base on CPython implementation
-
Boxiang Sun authored
-
- 10 Aug, 2015 11 commits
-
-
Kevin Modzelewski authored
microoptimizations
-
Kevin Modzelewski authored
rewrite additional nonzero() cases
-
Kevin Modzelewski authored
- improve bool and str hash() speed - optimize str.find(char)
-
Kevin Modzelewski authored
Use profiling to know when to throw CAPI exceptions
-
Kevin Modzelewski authored
Rewrite string hash and enable test_hash
-
Kevin Modzelewski authored
if we OSR out of a function, make sure we use the same exception style for the OSR'd version. We could also have the OSR exit code deal with switching exception styles, but for now it doesn't feel worth it.
-
Marius Wachtler authored
-
Kevin Modzelewski authored
Enable validation of printf-style format strings
-
Kevin Modzelewski authored
I had added the ability but forgot to turn it on.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
And fix some of the issues that this found.
-
- 09 Aug, 2015 7 commits
-
-
Kevin Modzelewski authored
Also, allow reraising using CAPI exceptions.
-
Kevin Modzelewski authored
Clean up our exception handling
-
Kevin Modzelewski authored
I use like to use test/tests/t.py and t2.py as temporary test files, so that they can get hooked into the makefile helpers, but the tester ignores them. Do this for t3.py too.
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
It was pretty unwieldy and handled some disparate parts of the exception-raising process. I think things are a bit cleaner now: - cxx_unwind.cpp handles C++ unwinding semantics - unwinding.cpp converts C stacks to Python stacks - exceptions.cpp takes Python stack frames and handles them appropriately So for throwing a C++ exception, it starts out in cxx_unwind.cpp, which then hands off the C frames to unwinding.cpp, which then hands off the Python frames to exceptions.cpp. When we get exceptions not via uncaught C++ exceptions (ie explicitly handled C++ exceptions or CAPI exceptions), those go directly into exceptions.cpp. There are also non-exception cases that we want to get the Python stack trace (ex sys._getframe), and those are handled by unwinding.cpp
-
Kevin Modzelewski authored
We have a couple different ways of walking the C stack (C++ exception unwinding and non-destructing stack crawling), and they both want to do this to reconstruct the Python stack. Extract out the common code.
-
Kevin Modzelewski authored
It had gotten pretty ad hoc. There were two things it was doing - some things dealing with unwinding; moved those to codegen/unwinding.cpp - most of our exception-throwing logic; moved these to a new runtime/exceptions.cpp
-
- 08 Aug, 2015 6 commits
-
-
Kevin Modzelewski authored
Be able to jit functions that throw CAPI exceptions
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
In theory should help with pyxl which throws a decent number of StopIterations from calling generator.next() directly, but pretty few of those calls actually make it into the llvm JIT to benefit from this.
-
Kevin Modzelewski authored
(Not enabled yet)
-
Kevin Modzelewski authored
Our IR doesn't explicitly represent the data transfer between an Invoke statement and its corresponding LandingPad. We use a couple different techniques to pass it through: in the ast interpreter/bjit, we stash it into an interpreter-local variable and then pull it back out. Previous to this change, in the LLVM tier we would pass it directly through an exception, using either the C++ or CAPI exception-passing mechanism. This works but is a pain, since it requires coordination between the invoke and the landingpad. These live in different basic blocks, so we ended up having this other code that lives separate from the normal irgen that has to decide which exception style to use, and it has to respect certain restrictions within irgen (ie it has to be careful to not request CAPI exceptions for cases that we haven't added support for yet). This commit changes the approach so that the exception data is passed directly as LLVM Values, and its up to the Invoke to figure out how to get it into that form. This adds a bit more complexity to the invoke, but it should make the interface easier to extend (such as in the next commit).
-
Kevin Modzelewski authored
Which piggy-back on the integration tests for getting their dependencies.
-
- 07 Aug, 2015 9 commits
-
-
Kevin Modzelewski authored
fix a few generator problems
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Boxiang Sun authored
-
Marius Wachtler authored
this all showed up by running test/cpython/test_generators.py sadly there are still a few until we can run the whole test
-
Kevin Modzelewski authored
-
Kevin Modzelewski authored
Rewrite unaryop and property get
-