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

Enable/disable optimizations #1125

Open
robertwb opened this issue Jul 31, 2010 · 1 comment
Open

Enable/disable optimizations #1125

robertwb opened this issue Jul 31, 2010 · 1 comment

Comments

@robertwb
Copy link
Contributor

Currently, the only way to do this is to comment out certain phases of the pipeline. Unfortunately, some of the optimization phases are necessary and/or change the semantics of the code (or result in broken compiles). This should be fixed.

Migrated from http://trac.cython.org/ticket/565

@robertwb
Copy link
Contributor Author

scoder commented

It would be quite simple to give somewhat abstract names to each of the optimisations (e.g. "iteration.string", "iteration.enumerate", "control.inlist", "builtin.all", "builtin.list.append") that are easy to map to methods in the optimisation transform classes. That way, we could simply intercept the dispatchers in these classes and check if the optimisation was explicitly disabled. We could also support wildcards like "list.*".

Most of the "feature implementations" that currently live in Optimize.py are just special cases of unimplemented features (e.g. all(genexp) while lacking generator expressions in general). Or think of slicing pointers, which doesn't work anywhere outside of iteration (see e.g. the carray iteration transform method). It's clear that these things break the compilation when being disabled, so we might want to exclude them from the enable/disable mechanism.

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

No branches or pull requests

1 participant