LLVM with the emscripten fastcomp javascript backend https://git.amat.us/emscripten-fastcomp/atom/lib/Transforms/IPO?h=master 2014-03-06T19:54:11Z 2014-03-06T19:54:11Z Dan Gohman sunfish@mozilla.com 2014-03-06T19:51:23Z urn:sha1:d644d4a9ca114ceb5d6e69f0c0df6cd571bb33c4 This is a backport of r197178 from LLVM trunk. 2014-02-28T20:39:49Z Dan Gohman sunfish@mozilla.com 2014-02-28T20:39:49Z urn:sha1:dc59054db06864099c1b1051b8ef28a30f13e6c7 When GlobalOpt has determined that a GlobalVariable only ever has two values, it would convert the GlobalVariable to a boolean, and introduce SelectInsts at every load, to choose between the two possible values. These SelectInsts introduce overhead and other unpleasantness. This patch makes GlobalOpt just add range metadata to loads from such GlobalVariables instead. This enables the same main optimization (as seen in test/Transforms/GlobalOpt/integer-bool.ll), without introducing selects. The main downside is that it doesn't get the memory savings of shrinking such GlobalVariables, but this is expected to be negligible. 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-09T22:29:37Z Eli Bendersky eliben@chromium.org 2013-07-09T22:29:37Z urn:sha1:299c82a21a9fd010534ea59c46ae0b88c21f25b7 GlobalOpt currently assumes only an external "main" is the "real main". This is no longer the case for PNaCl, where we internalize "main". Make the test more strict and PNaCl specific by checking that "main" is just used once - in a call from "_start", but does not have to be external. Note that this also addresses a possible bug in the optimization for C code, since C does not guarantee that main is not recursive. This CL's purpose is to address a SPEC performance regression - 10% in 183.equake. The regression appeared after our ABI change that made 'main' internal, which disabled this particular optimization. The CL addresses this by re-enabling the optimization and also being more C-standard conforming. BUG=None Review URL: https://codereview.chromium.org/18615015 2013-05-15T18:16:42Z Bill Wendling isanbard@gmail.com 2013-05-15T18:16:42Z urn:sha1:5b85a9b5ad98e06c836c8d9cd0e0e016ecea2f06 ------------------------------------------------------------------------ r181524 | rafael | 2013-05-09 10:22:59 -0700 (Thu, 09 May 2013) | 4 lines Don't replace an alias in llvm.used with its target. When we replace an internal alias with its target, be careful not to replace the entry in llvm.used (and llvm.compiler_used). ------------------------------------------------------------------------ git-svn-id: https://llvm.org/svn/llvm-project/llvm/branches/release_33@181909 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-06T01:48:55Z Rafael Espindola rafael.espindola@gmail.com 2013-05-06T01:48:55Z urn:sha1:eaf14786ca3975266ed7041ac242122c02baf1cf We used to disable constant merging not only if a constant is llvm.used, but also if an alias of a constant is llvm.used. This change fixes that. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181175 91177308-0d34-0410-b5e6-96231b3b80d8 2013-05-01T20:59:00Z Filip Pizlo fpizlo@apple.com 2013-05-01T20:59:00Z urn:sha1:40be1e85665d10f5444186f0e7106e368dd735b8 the things, and renames it to CBindingWrapping.h. I also moved CBindingWrapping.h into Support/. This new file just contains the macros for defining different wrap/unwrap methods. The calls to those macros, as well as any custom wrap/unwrap definitions (like for array of Values for example), are put into corresponding C++ headers. Doing this required some #include surgery, since some .cpp files relied on the fact that including Wrap.h implicitly caused the inclusion of a bunch of other things. This also now means that the C++ headers will include their corresponding C API headers; for example Value.h must include llvm-c/Core.h. I think this is harmless, since the C API headers contain just external function declarations and some C types, so I don't believe there should be any nasty dependency issues here. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180881 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-22T22:47:22Z Eric Christopher echristo@gmail.com 2013-04-22T22:47:22Z urn:sha1:3e39731e88f2d4f597cebc74388fd6650ca4f604 or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180063 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-22T14:58:02Z Rafael Espindola rafael.espindola@gmail.com 2013-04-22T14:58:02Z urn:sha1:cde25b435a907e7741da0c0d18953850936277c4 Also add a check for llvm.used in the verifier and simplify clients now that they can assume they have a ConstantArray. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180019 91177308-0d34-0410-b5e6-96231b3b80d8 2013-04-19T23:06:44Z Benjamin Kramer benny.kra@googlemail.com 2013-04-19T23:06:44Z urn:sha1:24a5f30f77fa2890329fa3a9165b54c13bbd51e7 The logic that actually compares the types considers pointers and integers the same if they are of the same size. This created a strange mismatch between hash and reality and made the test case for this fail on some platforms (yay, test cases). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179905 91177308-0d34-0410-b5e6-96231b3b80d8