LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/include/llvm/Support?h=master 2013-07-15T23:09:15Z 2013-07-15T23:09:15Z Eli Bendersky eliben@chromium.org 2013-07-15T23:09:15Z urn:sha1:c6cf05cb5108f356dde97c01ee4188b0671d4542 Conflicts: docs/LangRef.rst include/llvm/CodeGen/CallingConvLower.h include/llvm/IRReader/IRReader.h include/llvm/Target/TargetMachine.h lib/CodeGen/CallingConvLower.cpp lib/IRReader/IRReader.cpp lib/IRReader/LLVMBuild.txt lib/IRReader/Makefile lib/LLVMBuild.txt lib/Makefile lib/Support/MemoryBuffer.cpp lib/Support/Unix/PathV2.inc lib/Target/ARM/ARMBaseInstrInfo.cpp lib/Target/ARM/ARMISelLowering.cpp lib/Target/ARM/ARMInstrInfo.td lib/Target/ARM/ARMSubtarget.cpp lib/Target/ARM/ARMTargetMachine.cpp lib/Target/Mips/CMakeLists.txt lib/Target/Mips/MipsDelaySlotFiller.cpp lib/Target/Mips/MipsISelLowering.cpp lib/Target/Mips/MipsInstrInfo.td lib/Target/Mips/MipsSubtarget.cpp lib/Target/Mips/MipsSubtarget.h lib/Target/X86/X86FastISel.cpp lib/Target/X86/X86ISelDAGToDAG.cpp lib/Target/X86/X86ISelLowering.cpp lib/Target/X86/X86InstrControl.td lib/Target/X86/X86InstrFormats.td lib/Transforms/IPO/ExtractGV.cpp lib/Transforms/InstCombine/InstCombineCompares.cpp lib/Transforms/Utils/SimplifyLibCalls.cpp test/CodeGen/X86/fast-isel-divrem.ll test/MC/ARM/data-in-code.ll tools/Makefile tools/llvm-extract/llvm-extract.cpp tools/llvm-link/CMakeLists.txt tools/opt/CMakeLists.txt tools/opt/LLVMBuild.txt tools/opt/Makefile tools/opt/opt.cpp 2013-07-09T17:44:24Z Jan Voung jvoung@chromium.org 2013-07-09T17:44:24Z urn:sha1:d7676885204bbc165a8b27a537777bfe450e6323 Saves about 100KB per arch. As noted in the test, some of the functions like getRegisterName() are not pruned. Common infrastructure code may still be sitting around, only the ${ARCH}InstPrinter::* is touched... but this is just a one-liner. BUG=https://code.google.com/p/nativeclient/issues/detail?id=1222 TEST=https://codereview.chromium.org/18333008/ R=dschuff@chromium.org Review URL: https://codereview.chromium.org/18238011 2013-05-10T23:00:11Z Derek Schuff dschuff@chromium.org 2013-05-10T23:00:11Z urn:sha1:52daf9d821c963f84dd312ff90921bfe1b1cc0a1 This is needed to switch the native linker to one based on upstream binutils 2.23 R=mseaborn@chromium.org BUG= https://code.google.com/p/nativeclient/issues/detail?id=2971 also related to bug https://code.google.com/p/nativeclient/issues/detail?id=3424 Review URL: https://codereview.chromium.org/15067009 2013-05-06T21:56:35Z Andrew Trick atrick@apple.com 2013-05-06T21:56:35Z urn:sha1:61e01721978af4c2979c4b9153e56e72eb6389fb Patch by Dan Liew! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181254 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T21:56:23Z Andrew Trick atrick@apple.com 2013-05-06T21:56:23Z urn:sha1:b7ad33b7195cb99b0cbb1c5308324d328650ca45 Patch by Dan Liew! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181253 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T16:55:50Z Jean-Luc Duprat jduprat@apple.com 2013-05-06T16:55:50Z urn:sha1:c5cf6e536598a3b1e30fce616b771d66a071a54c A * (1 - (uitofp i1 C)) -> select C, 0, A B * (uitofp i1 C) -> select C, B, 0 select C, 0, A + select C, B, 0 -> select C, B, A These come up in code that has been hand-optimized from a select to a linear blend, on platforms where that may have mattered. We want to undo such changes with the following transform: A*(1 - uitofp i1 C) + B*(uitofp i1 C) -> select C, A, B git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181216 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-05T02:01:41Z Arnold Schwaighofer aschwaighofer@apple.com 2013-05-05T02:01:41Z urn:sha1:f127be1e380d47d4c6588c7445a4db90f98ab534 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181146 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-05T01:54:46Z Arnold Schwaighofer aschwaighofer@apple.com 2013-05-05T01:54:46Z urn:sha1:e79d92c592d75e210dbe3abe1a975e859d17e953 Add support for matching 'ordered' and 'unordered' floating point min/max constructs. In LLVM we can express min/max functions as a combination of compare and select. We have support for matching such constructs for integers but not for floating point. In floating point math there is no total order because of the presence of 'NaN'. Therefore, we have to be careful to preserve the original fcmp semantics when interpreting floating point compare select combinations as a minimum or maximum function. The resulting 'ordered/unordered' floating point maximum function has to select the same value as the select/fcmp combination it is based on. ordered_max(x,y) = max(x,y) iff x and y are not NaN, y otherwise unordered_max(x,y) = max(x,y) iff x and y are not NaN, x otherwise ordered_min(x,y) = min(x,y) iff x and y are not NaN, y otherwise unordered_min(x,y) = min(x,y) iff x and y are not NaN, x otherwise This matches the behavior of the underlying select(fcmp(olt/ult/.., L, R), L, R) construct. Any code using this predicate has to preserve this semantics. A follow-up patch will use this to implement floating point min/max reductions in the vectorizer. radar://13723044 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181143 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-05T00:40:33Z Dmitri Gribenko gribozavr@gmail.com 2013-05-05T00:40:33Z urn:sha1:5c332dbd30d9398ed25b30c3080506f7b8e92290 Patch by Robert Wilhelm. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181138 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-03T11:11:15Z Richard Sandiford rsandifo@linux.vnet.ibm.com 2013-05-03T11:11:15Z urn:sha1:820b3fd7716cf5ab26961d1b2b21fd5d0f330fe1 Another step towards reinstating the SystemZ backend. Tests will be included in the main backend patch. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181008 91177308-0d34-0410-b5e6-96231b3b80d8