- Jul 16, 2013
-
-
Rafael Espindola authored
This centralizes the handling of O_BINARY and opens the way for hiding more differences (like how open behaves with directories). llvm-svn: 186447
-
Benjamin Kramer authored
llvm-svn: 186445
-
Rafael Espindola authored
llvm-svn: 186444
-
Benjamin Kramer authored
llvm-svn: 186442
-
Benjamin Kramer authored
llvm-svn: 186439
-
Manman Ren authored
llvm-svn: 186436
-
Jakob Stoklund Olesen authored
These floats all represented block frequencies anyway, so just use the BlockFrequency class directly. Some floating point computations remain in tryLocalSplit(). They are estimating spill weights which are still floats. llvm-svn: 186435
-
Jakob Stoklund Olesen authored
Original commit message: Remove floating point computations from SpillPlacement.cpp. Patch by Benjamin Kramer! Use the BlockFrequency class instead of floats in the Hopfield network computations. This rescales the node Bias field from a [-2;2] float range to two block frequencies BiasN and BiasP pulling in opposite directions. This construct has a more predictable behavior when block frequencies saturate. The per-node scaling factors are no longer necessary, assuming the block frequencies around a bundle are consistent. This patch can cause the register allocator to make different spilling decisions. The differences should be small. llvm-svn: 186434
-
Juergen Ributzka authored
Use PMIN/PMAX for UGE/ULE vector comparions to reduce the number of required instructions. This trick also works for UGT/ULT, but there is no advantage in doing so. It wouldn't reduce the number of instructions and it would actually reduce performance. Reviewer: Ben radar:5972691 llvm-svn: 186432
-
Peter Collingbourne authored
Differential Revision: http://llvm-reviews.chandlerc.com/D1149 llvm-svn: 186431
-
Juergen Ributzka authored
llvm-svn: 186429
-
Reid Kleckner authored
This is to support parsing UTF16 response files in LLVM/lib/Option for lld and clang. Reviewers: hans Differential Revision: http://llvm-reviews.chandlerc.com/D1138 llvm-svn: 186426
-
Hal Finkel authored
For safety, the inliner cannot decrease the allignment on an alloca when merging it with another. I've included two variants of the test case for this: one with DataLayout available, and one without. When DataLayout is not available, if only one of the allocas uses the default alignment (getAlignment() == 0), then they cannot be safely merged. llvm-svn: 186425
-
Rafael Espindola authored
With this change llvm-ar can remove the temporary file on windows too. llvm-svn: 186423
-
Nadav Rotem authored
Process groups of stores in chunks of 16. llvm-svn: 186420
-
Rafael Espindola authored
llvm-svn: 186414
-
Reid Kleckner authored
llvm-svn: 186413
-
Ulrich Weigand authored
[APFloat] PR16573: Avoid losing mantissa bits in ppc_fp128 to double truncation When truncating to a format with fewer mantissa bits, APFloat::convert will perform a right shift of the mantissa by the difference of the precision of the two formats. Usually, this will result in just the mantissa bits needed for the target format. One special situation is if the input number is denormal. In this case, the right shift may discard significant bits. This is usually not a problem, since truncating a denormal usually results in zero (underflow) after normalization anyway, since the result format's exponent range is usually smaller than the target format's. However, there is one case where the latter property does not hold: when truncating from ppc_fp128 to double. In particular, truncating a ppc_fp128 whose first double of the pair is denormal should result in just that first double, not zero. The current code however performs an excessive right shift, resulting in lost result bits. This is then caught in the APFloat::normalize call performed by APFloat::convert and causes an assertion failure. This patch checks for the scenario of truncating a denormal, and attempts to (possibly partially) replace the initial mantissa right shift by decrementing the exponent, if doing so will still result in a valid *target format* exponent. Index: test/CodeGen/PowerPC/pr16573.ll =================================================================== --- test/CodeGen/PowerPC/pr16573.ll (revision 0) +++ test/CodeGen/PowerPC/pr16573.ll (revision 0) @@ -0,0 +1,11 @@ +; RUN: llc < %s | FileCheck %s + +target triple = "powerpc64-unknown-linux-gnu" + +define double @test() { + %1 = fptrunc ppc_fp128 0xM818F2887B9295809800000000032D000 to double + ret double %1 +} + +; CHECK: .quad -9111018957755033591 + Index: lib/Support/APFloat.cpp =================================================================== --- lib/Support/APFloat.cpp (revision 185817) +++ lib/Support/APFloat.cpp (working copy) @@ -1956,6 +1956,23 @@ X86SpecialNan = true; } + // If this is a truncation of a denormal number, and the target semantics + // has larger exponent range than the source semantics (this can happen + // when truncating from PowerPC double-double to double format), the + // right shift could lose result mantissa bits. Adjust exponent instead + // of performing excessive shift. + if (shift < 0 && isFiniteNonZero()) { + int exponentChange = significandMSB() + 1 - fromSemantics.precision; + if (exponent + exponentChange < toSemantics.minExponent) + exponentChange = toSemantics.minExponent - exponent; + if (exponentChange < shift) + exponentChange = shift; + if (exponentChange < 0) { + shift -= exponentChange; + exponent += exponentChange; + } + } + // If this is a truncation, perform the shift before we narrow the storage. if (shift < 0 && (isFiniteNonZero() || category==fcNaN)) lostFraction = shiftRight(significandParts(), oldPartCount, -shift); llvm-svn: 186409
-
Richard Osborne authored
Previously an asm operand with no operand modifier would give the error "invalid operand in inline asm". llvm-svn: 186407
-
Tim Northover authored
We'd forgotten to provide string representations for the special ARMISD atomic nodes; this adds them in. No effect on CodeGen, just makes the output of "-view-whatever-dags" slightly more readable. llvm-svn: 186406
-
Richard Sandiford authored
llvm-svn: 186405
-
Vladimir Medic authored
llvm-svn: 186403
-
Richard Sandiford authored
CodeGen support will come later. llvm-svn: 186401
-
Richard Sandiford authored
Another patch in the series to make more use of R.SBG. This one extends r186072 and r186073 to handle cases where the AND is inside the shift. llvm-svn: 186399
-
Vladimir Medic authored
This patch represents Mips utilization of r186388 code that alows asm matcher to emit mnemonics contain '.' characters. This makes asm parser code simpler and more efficient. llvm-svn: 186397
-
NAKAMURA Takumi authored
g++ (GCC) 4.4.4 20100630 (Red Hat 4.4.4-10) llvm-svn: 186396
-
Tim Northover authored
Intrinsics already existed for the 64-bit variants, so these support operations of size at most 32-bits. llvm-svn: 186392
-
Renato Golin authored
This patch enables calls to __aeabi_idivmod when in EABI mode, by using the remainder value returned on registers (R1), enabled by the ARM triple "none-eabi". Note that Darwin and GNUEABI triples will continue lowering on GNU style, that is, using the stack for the remainder. Still need to add SREM/UREM support fix for 64-bit lowering. llvm-svn: 186390
-
Vladimir Medic authored
This patch allows targets to define weather the instruction mnemonics in asm matcher tables will contain '.' character. llvm-svn: 186388
-
NAKAMURA Takumi authored
llvm-svn: 186387
-
Rafael Espindola authored
llvm-svn: 186381
-
Rafael Espindola authored
This is a micro optimization. Instead of going char*->StringRef->Twine->char*, go char*->Twine->char* and avoid having to copy the filename on the stack. llvm-svn: 186380
-
Rui Ueyama authored
Summary: Add import_directory_table_entry to use for .idata section. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1059 llvm-svn: 186379
-
Rafael Espindola authored
llvm-svn: 186378
-
Rui Ueyama authored
llvm-svn: 186377
-
Rafael Espindola authored
This opens the way of having static helpers in the .inc files that can construct a file_status. llvm-svn: 186376
-
NAKAMURA Takumi authored
llvm-svn: 186375
-
NAKAMURA Takumi authored
llvm-ar is the only user of toWin32Time() (via setLastModificationAndAccessTime), and r186298 can be reverted. It had been buggy since the initial commit. FIXME: Could we rename {from|to}Win32Time as {from|to}Win32FILETIME in TimeValue? llvm-svn: 186374
-
NAKAMURA Takumi authored
llvm-svn: 186372
-
Craig Topper authored
llvm-svn: 186371
-