Use tbaa for heap-allocated immutables

[simonster]

This adds tbaa_immut metadata to loads/stores from/to heap-allocated immutables. I'm not entirely sure this is safe, since it is possible for a user to use pointer_from_objref and alter such immutables, but that would seem to go against the spirit of immutables and it's not possible for stack-allocated immutables in any case.

This addresses "hoist access to fields in immutable values" from #3440. It may not be the best we could possibly do, since the field accesses still can't be hoisted in a loop that makes function calls.

On my system, this combined with #8827 is sufficient to make the benchmark from #8809 faster for ContiguousViews than Arrays with @inbounds. (It shouldn't be faster, though. I think this has to do with suboptimal behavior from the LLVM 3.3 loop vectorizer, since the benchmark is twice as fast on an array with LLVM SVN as it is on 3.3.) It gives a speedup without @inbounds but doesn't erase the gap. The IR with bounds checks is very similar; I think the remaining overhead must come from the fact that the bounds checks for ContiguousViews are based on the length of the whole array rather than the length of the view.

[StefanKarpinski]

This is great stuff.

[vtjnash]

calling pointer_from_objref on an immutable (isbits) is already inherently a really bad idea (tm), since the memory it returned probably wasn't gc-rooted anywhere. it should probably be disallowed.

[StefanKarpinski]

Let's merge this.

[JeffBezanson]

+1

[simonster]

I wonder whether a more robust approach might be to mark loads from heap-allocated immutables created in other functions as !invariant.load and use llvm.invariant.start for heap-allocated immutables created in the same function (assuming it works, although this LLVM bug suggests it may not). It would be easier to use !invariant.load for immutables created in the same function as well, and the tests pass if I do, but I worry that LLVM could potentially consider the pointer to be "known dereferenceable" before the stores. The discussion here doesn't seem so clear to me.