Kernel-local regions

[eholk]

We should add a special region inside of kernels that lives in local (or shared) memory. Kernels could use this to allocate data that isn't actually returned from the kernel.

[eholk]

8694bc2 adds a hack that lets this work as long as you don't touch the region.

We'll want a proper fix soon, since function calls from kernels makes it a lot easier to get into this situation.

Fixing this is related to fixing #114 as well.

[eholk]

Here are some comments from that most recent commit about how I fixed it and what better solutions are.

+/*
+  FIXME: The next next bit is an awful hack for when kernel-local
+  regions leak into the compiled program. This tends to happen when
+  making lots of function calls from the kernel. Here we just use a
+  NULL pointer as the region, which works as long as we never touch
+  the region (for example, lambdas always have a region but it's often
+  not used).
+
+  Commented out below is an attempt I had to declare a tiny region on
+  the stack. Unfortunately, OpenCL makes a distinction between local
+  and global pointers, so we'd need versions of the function that work
+  on different pointer types. This will take some pretty invasive
+  changes to the type inferencer and the rest of the compiler, since
+  we'll have a notion of local and global regions.
+
+  Another option is to early on identify which functions are called by
+  kernels and generate two versions. The kernel version would not
+  allocate any regions, and instead rely on the callers to supply
+  them. This again complicates the type system and will require help
+  from the type inferencer.
+
+  Finally, we could modify the compiler (such as in
+  fix-kernel-local-regions) to just find a nearby region and use that
+  instead. It's a hack, but it is a fairly local change and I don't
+  think it introduces any unsoundness, unlike the way things are
+  currently.
+
+  I'll open an issue to keep track of this.
+
+*/