Faster float conversion operations

[m-ou-se]

This supersedes #370

This includes #463

[m-ou-se]

Currently, compiler_builtins contains two cases where a builtin is implemented by the native conversion on x86_64:

compiler-builtins/src/float/conv.rs

Lines 91 to 95 in 4117da3

	// On x86_64 LLVM will use native instructions for this conversion, we
	// can just do it directly
	if cfg!(target_arch = "x86_64") {
	i as f32
	} else {

I'm a bit confused by that. If i as f32 results in native code and not a call to compiler-builtins, then there doesn't seem to be much reason to optimize the version in compiler-builtins.

The version in this PR does not have those special cases. I can put them back if someone thinks they are actually useful.

[bjorn3]

I'm a bit confused by that. If i as f32 results in native code and not a call to compiler-builtins, then there doesn't seem to be much reason to optimize the version in compiler-builtins.

as f32 results in an intrinsic call on platforms that don't have a native version of this.

The version in this PR does not have those special cases. I can put them back if someone thinks they are actually useful.

I think it should be put back.

[m-ou-se]

as f32 results in an intrinsic call on platforms that don't have a native version of this.

Yes.. That's what I said. The special case is for a platform that does have a native version, which means this function wouldn't be called when someone does as f32.

I think it should be put back.

Why? When would it be used on x86_64?

[bjorn3]

Looks like it is also used in case of +soft-float. I guess that special case wouldn't be valid then though.

[Amanieu]

LGTM apart from a few style nits.

[Amanieu]

Removing this is fine, I'm not even sure why this hack was here in the first place. If LLVM generates a native instruction then this function is never called anyways. Except in the case of soft-float, in which case you specifically don't want to use the built-in instruction.

[nickdesaulniers]

Nice blog post; does it make sense to put any of these implementation in llvm's compiler-rt?

[m-ou-se]

does it make sense to put any of these implementation in llvm's compiler-rt?

@nickdesaulniers Sure! I don't have time for that, but if someone has time to port these implementations, that might benefit a lot of people :)