Stop forcing `i1` booleans to `i8` for comparison when LLVM is fixed

[bstrie]

The current behavior introduced by #36958 is a workaround for the bug at #36856 . In the comment at #36958 (comment) Niko mentions that this is worth removing when the upstream LLVM bug is fixed (per that comment's suggestion I'm also presumptuously tagging this as P-medium). I know we have an upgrade to LLVM 4.0 in the works ( #37609 ), so that may fix it. However, what is our policy on compiling on old versions of LLVM, for the sake of rustc distribution in distros that ship their own LLVM? If we need to remain compatible with old versions of LLVM, then the workaround may need to exist for quite a long time.

[nagisa]

However, what is our policy on compiling on old versions of LLVM, for the sake of rustc distribution in distros that ship their own LLVM?

We still support 3.7.

[bstrie]

The LLVM bug in question appears to be https://bugs.llvm.org/show_bug.cgi?id=30579 , which is now marked resolved. Presumably the workaround in #36958 can now be removed, so I'm marking this E-easy. However, don't just revert the commit itself; leave its test case intact.

[hanna-kruppe]

Comment 2 on the LLVM bug indicates the fix is in LLVM 4.0, but we still support LLVM 3.9, so we can't actually do this just yet.

[krk]

Is LLVM 3.9 still supported? @rkruppe

[hanna-kruppe]

I'm not aware of any changes. Indeed we still have a CI image that builds with LLVM 3.9.

[hanna-kruppe]

Huh, I've only just seen https://bugs.llvm.org/show_bug.cgi?id=30579#c3 -- if this is correct, there was never any need to work around it, we could have just dropped our (incorrect) FastISel patch. Does someone have to have a (non-rustc) LLVM 3.9 build available to try and reproduce?

[hanna-kruppe]

@nox was so kind as to check, and indeed stock LLVM 3.9 doesn't have the bug.