Conflicts:
	src/codegen/irgen/hooks.cpp
	src/codegen/irgen/irgenerator.cpp
	src/core/types.h

(Though most libraries will probably crash)

Fix make check: Order includes alphabetical

Fix reversing of >, <, <= and >= compare operations

Just noticed that they are also wrong

Required a bit of refactoring in terms of how
parameter specifiers are passed around.

Well not sure if it's a deadlock; I think we try to
re-entrantly acquire the codegen lock, which then
confuses it later?

GC: Register None

Implement chained comparisons

Merges #88

Conflicts:
	src/core/threading.cpp

Not sure why greg_t got changed from 'long' to 'long long' in newer versions of glibc; just cast it to be compatible

Build fix

Signed-off-by: Vinzenz Feenstra <evilissimo@gmail.com>

Implementation is pretty straightforward for now:
- find all names that get accessed from a nested function
- if any, create a closure object at function entry
- any time we set a name accessed from a nested function,
  update its value in the closure
- when evaluating a functiondef that needs a closure, attach
  the created closure to the created function object.

Closures are currently passed as an extra argument before any
python-level args, which I'm not convinced is the right strategy.
It's works out fine but it feels messy to say that functions
can have different C-level calling conventions.
It felt worse to include the closure as part of the python-level arg
passing.
Maybe it should be passed after all the other arguments?

Closures are currently just simple objects, on which we set and get
Python-level attributes.  The performance (which I haven't tested)
relies on attribute access being made fast through the hidden-class
inline caches.

There are a number of ways that this could be improved:
- be smarter about when we create the closure object, or when we
  update it.
- not create empty pass-through closures
- give the closures a pre-defined shape, since we know at irgen-time
  what names can get set.  could probably avoid the inline cache
  machinery and also have better code.

Enable the VTune JIT support in llvm, and add it as a jit
listener.

I think it's mostly confirming my suspicion that the slowdown is
cache-related... it's not being very helpful with determining why
(it's in some function that it can't analyze).

I updated the memory allocator to have strong thread-affinity
(ie a thread now generally gets back memory that it had previously freed),
but that doesn't seem to have any effect.

Going to punt on further investigations for now, pretty happy though that there's
an overall speedup with the grwl, even if there are still issues.

Turns out a large amount of thread contention was coming from these shared counters -- disable some of them and add some thread-local caching

insert full blocks back at the end of the free list to hopefully reduce the amount of times we have to check them

Now, threads will claim an entire block at a time, and
put it in a thread-local cache.  In the common case, they
can allocate out of this block, and only need to take out
a lock if they run out.