I reverted r277786 in the meantime (in r277909)

Preprocessed testcase
Compile the attached file with:

$ clang -Ofast fbench.i -fblocks -o a.out -lm -mllvm -gvn-max-hoisted=63
$ ./a.out
[...]
93 errors in results. This is VERY SERIOUS.

$ clang -Ofast fbench.i -fblocks -o a.out -lm -mllvm -gvn-max-hoisted=62
$ ./a.out
[...]
No errors in results.

MSSA with -gvn-max-hoisted=62

MSSA with -gvn-max-hoisted=63

Complete dump you can use to see incorrect version
use opt -tbaa -print-memoryssa to see:

if.then22: ; preds = %if.then20
; 7 = MemoryDef(liveOnEntry)
store double 0.000000e+00, double* @​axis_slope_angle, align 8, !tbaa !​3
...

; 13 = MemoryPhi({if.then22,7},{if.else24,liveOnEntry})
...

; MemoryUse(liveOnEntry)
%22 = load double, double* @​axis_slope_angle, align 8, !tbaa !​3

Reduced version of testcase

This is a silly bug: We are trying to figure out whether the size of the stack has changed due to popping off non-dominating accesses,and we are not doing it right:

We were doing:
if (LocInfo.LowerBound >= VersionStack.size() - 1) {

To see if the lower bound needed to be reset after popping the stack.
The problem with this is that if you have any pushes, it may be that the lower bound is still wrong, the size will still now be "right".

The correct fix is to store the size of the stack after we are done popping, and use it in the comparison above.

Ironically, I had thought about this, and in the first versions of the use optimizer i sent george, we were storing the stack size, but i couldn't remember why we needed to do that so i removed it :)

I'll fix this and add a testcase.

Patch that should fix it

Fixed in https://reviews.llvm.org/rL277978
and enabled gvn-hoist by default in https://reviews.llvm.org/rL278010