Unbreak the !unconditionally_dereferenceable LLVM patch

[whitequark]

See the discussion in https://reviews.llvm.org/D18738. Sanjoy Das is convinced that it is unsound. Although I am not quite as convinced his approach is cleaner and could be merged upstream.

[whitequark]

Triage: the upstream still cannot agree on the desired semantics for a feature like this: https://reviews.llvm.org/D20116. I am now more convinced that the patch we have is, in fact, unsound.

[whitequark]

D20116 is in.

[jordens]

@whitequark is this now merely a consolidation/upstreaming thing or should/would the semantics change?

[whitequark]

@jordens The upstreamed patch is the equivalent of our patch but for function calls rather than loads and it is immediately useless to us in its current form. (It might be useful for other things, not sure yet.) However the argument that allowed it to get in can be used when revisiting !unconditionally_dereferenceable and we should do that.

[whitequark]

Per correspondence with LLVM developers, the patch is broken by design and cannot be fixed (and likely can lead to miscompilations already). We'll have to find some other way of improving the performance of the loops it was used to speed up.