It's easier to tell the two constants apart if they are different.

They tends to time out or just make the test suite run for longer. They definitely times out
when running a prototype moving gc.

Scan constants written into compiled code.

A GC could happen during the rewrite.

Scan rewriters for interior pointers

We need to do this because the ICInvalidator pointers are stored inside
Pyston heap objects.

Some improvments that let test_index could pass

Sqlalchemy compatibility fixes

Sqlalchemy subclasses set, and overrides __init__ and does some
custom initialization there.  We were doing the initialization in
__new__, which works most of the time, except if a generator was
passed since then sqlalchemy's initialization will see what looks
like an empty generator since we already consumed it.

So move the initialization to init.  Except for frozenset which still
needs to do it in new.

In CPython, str.add directly throws a TypeError since it is implemented
as a sq_concat.  sqlalchemy relies on being able to do str()+MyStr() and
use MyStr.__radd__ to handle the addition.  We were throwing a TypeError
but not implementing it in sq_concat.

So instead, return NotImplemented instead of directly throwing a TypeError.
This makes '+' more compatible but str.__add__ a bit less compatible.

add _PyLong_Copy implementation, return a copy in PyNumber_Long if the type of argument is long or long subclass

Add override keyword where necessary.

Generate better module names to make the object cache more effective

add tp_nextiter implementation for our iterators

one of the problems were that depending on if all files were all ready parsed we JITed more or less functions,
this changed the total number of jited functions which changed all the module names.
This lead to the result that in order to have all entries inside the cache we needed at least 3runs if the pyc files were old.

The whole name scheme should add some point get improved but for now it should be enough.

Lower initial dict/set size from 64->8

Support non-module-globals in the llvm tier

By switching to our DenseMap/Set fork with that allows parameterizing
on this.

This is the same number that CPython uses.  We were previously
using llvm's default of 64, which is pretty high -- probably fine
for their use cases, but in Python programs with lots of sets/dicts
we spend a lot of time doing malloc() for all those 1kB+ allocations.
This also increases the time it takes to iterate over the dict/set,
since there are more empty buckets that have to be read + skipped.

The default is 64, which is quite a lot for our uses.

- add note + license
- put in our namespace
- change header guards
- make it match our lint style
- don't apply our formatting

With no modificaions in this commit, so that we can track changes.
Unmodified from llvm rev r230300.

It does use the old parser, but it also forces the use
of the llvm tier for everything which usually ends up being
the more important part of the configuration.

(motivated by namedtuple)

This involves two main changes:
- changing the calling convention to pass `globals` as an argument if needed
  (this only applies going into compiled code, it's already passed into the interpreter)
- changing the llvm irgenerator to use the new globals object

Notion of redundant visits to slowly move towards scanning everything

Complex improment