WIP: Generalize float intrinsics

[Keno]

Unfortunately Float16 support is broken in LLVM (who could have guessed that a type not used by Clang is broken ...).

Anyway, once I fix that in LLVM, this closes #3467

[ViralBShah]

Pretty cool. I no longer find it odd that types not used by Clang can be broken in LLVM. We really should work towards getting your patches accepted upstream.

[StefanKarpinski]

I posted this on an earlier version of this change:

This is a beautiful change, Keno. I didn't actually realize quite how extensive the changes required for this would be, but this adds Float16 functionality while reducing the code size by 26 lines. Bravo.

Even though LLVM's Float16 support is broken, we should still merge the generalization stuff into master. To provide non-broken Float16 support, we can either

1. use the user-land Float16 conversion code that @rwgardner posted [https://github.com/Float16 type #3467#issuecomment-19908358];
2. patch our own copy of LLVM with fixes for various numeric types, including the Int128 and Float16 fixes.

It might be time to start maintaining our own fork of LLVM, although that's a big undertaking. At the very least, we need to start pursuing getting fixes accepted into LLVM. It seems like Julia may be the premiere use case for "exotic" numeric types in LLVM at this point.

[StefanKarpinski]

@loladiro, how about separating this into two commits: one doing the generalization and a second adding the Float16 type? The first one can be merged into master as long as everything continues to work correctly, while the second should be a tiny patch that we can keep around until we figure out what to do.

[StefanKarpinski]

This is also the last set of intrinsics to be generalized to arbitrary size, aside from the mixed-type comparisons, which are unnecessary for smaller types like Float32 and thus only make sense for 64-bit (although we'll need larger versions if we ever add Float128 or other large floating-point types).

[Keno]

@JeffBezanson There seems to be a lot of repeated code between generic_(un)box, try_to_determine_bitstype_nbits and staticeval_bitstype. Any subtle reason not to consolidate these, I'm missing?

@StefanKarpinski Yes, I will split this patch. I didn't really get very far with Float16 support anyway, as it's completely unusable with current LLVM.

[JeffBezanson]

Very good!

How broken is Float16 in LLVM? Is it a small bug that can be fixed to make everything work, or is it a larger project? If it will take a while or isn't likely to be accepted, we can get started just by having the type and conversions to/from Float32 as Stefan said.

[Keno]

Here's the upstream bug, for reference: http://llvm.org/bugs/show_bug.cgi?id=16491.

The obvious problem is deceptively simple in that they simply made the assumption that 32bit is the smallest they'll ever encounter. Considering this is not at all tested in the LLVM codebase though, I wouldn't be surprised if more was broken.

[Keno]

Alright. I switched the argument order and commented out the Float16 definitions, so this should be good to merge. I'll try to fix the Float16 issue in LLVM. Feel free to do whatever to Float16 in the mean time.

[ViralBShah]

I found the llvm-dev mailing dist discussion useful too:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-June/062968.html

[ViralBShah]

Is it possible to get this into 0.2, given the LLVM patches?

[StefanKarpinski]

The LLVM changes are only necessary to support Float16 correctly, so this can be merged without affecting behavior.

[StefanKarpinski]

I've tested and it seems all good and looks good to me. Travis say it's ok too, so @loladiro, go ahead an merge whenever you're ready. I think this should just go into master and we can add the Float16 stuff whenever/however.

[Keno]

Merged!