llvm-svn: 92201

Allow targets to specify the return type of libcalls that are generated for floating point comparisons, rather than hard-coding them as i32.

llvm-svn: 92199

llvm-svn: 92198

llvm-svn: 92197

llvm-svn: 92196

llvm-svn: 92195

llvm-svn: 92194

llvm-svn: 92193

llvm-svn: 92192

llvm-svn: 92191

llvm-svn: 92190

llvm-svn: 92189

llvm-svn: 92188

llvm-svn: 92187

llvm-svn: 92186

llvm-svn: 92185

llvm-svn: 92184

llvm-svn: 92183

llvm-svn: 92182

mainly used in debugging and/or assert situations. It should make the compiler
and the static analyzer stop nagging us about them.

llvm-svn: 92181

llvm-svn: 92180

llvm-svn: 92179

llvm-svn: 92178

llvm-svn: 92169

llvm-svn: 92168

do illegal stuff around it.  No testcase because the issue is very fragile.

llvm-svn: 92167

llvm-svn: 92160

llvm-svn: 92159

llvm-svn: 92158

llvm-svn: 92157

llvm-svn: 92156

llvm-svn: 92155

major bugs in long-precision conversion.

llvm-svn: 92150

will be found by argument-dependent lookup. As with the previous
commit, GCC is allowing ill-formed code.

llvm-svn: 92146

argument-dependent lookup can find it. This is another case where an
LLVM bug (not making operator<< visible) was masked by a GCC bug
(looking in the global namespace when it shouldn't).

llvm-svn: 92144

llvm-svn: 92133

cut the significand down to the desired precision *before* entering the
core divmod loop.  Makes the overall algorithm logarithmic in the exponent.

There's still a lot of room for improvement here, but this gets the
performance back down to acceptable-for-diagnostics levels, even for
long doubles.
negligible, even on long doubles.

llvm-svn: 92130

smallest-normalized-magnitude values in a given FP semantics.
Provide an APFloat-to-string conversion which I am quite ready to admit could
be much more efficient.

llvm-svn: 92126

order should be immune to such problems.

llvm-svn: 92124

llvm-svn: 92110