search for: loadstor

On Fri, Jul 8, 2011 at 9:30 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 07/ 8/11 05:26 PM, Eli Friedman wrote: >> >> Given that revision range, the only remotely likely culprit is 131463. >>  Which basically means that it "broke" because the default target >> features changed. > > And you are right here. 131463 == 131464 which is

On 07/ 8/11 05:26 PM, Eli Friedman wrote: > Given that revision range, the only remotely likely culprit is 131463. > Which basically means that it "broke" because the default target > features changed. And you are right here. 131463 == 131464 which is buggy. 131462 is OK. Thanks, Karel

In r200270 I added support to unroll conditional stores in the loop vectorizer. It is currently off pending further benchmarking and can be enabled with "-mllvm -vectorize-num-stores-pred=1”. Furthermore, I added a heuristic to unroll until load/store ports are saturated “-mllvm enable-loadstore-runtime-unroll” instead of the pure size based heuristic. Those two together with a patch that slightly changes the register heuristic and libquantum’s three hot loops will unroll and goodness will ensue (at least for libquantum). commit 6b908b8b1084c97238cc642a3404a4285c21286f Author: Arnold S...

...fp-no-external-funcs.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: ExecutionEngine/test-global-init-nonzero.ll LLVM :: ExecutionEngine/test-global.ll LLVM :: ExecutionEngine/test-interp-vec-arithm_float.ll LLVM :: ExecutionEngine/test-interp-vec-arithm_int.ll LLVM :: ExecutionEngine/test-interp-vec-loadstore.ll LLVM :: ExecutionEngine/test-interp-vec-logical.ll LLVM :: ExecutionEngine/test-interp-vec-setcond-fp.ll LLVM :: ExecutionEngine/test-interp-vec-setcond-int.ll LLVM :: ExecutionEngine/test-loadstore.ll LLVM :: ExecutionEngine/test-local.ll LLVM :: ExecutionEngine/test-logical.ll LLVM :: Executi...

...ine 2: 28423 Aborted '/nfs_home/chenwj/test/native-build/arm2/Debug+Asserts/bin/lli' '/nfs_home/chenwj/test/llvm/test/ExecutionEngine/test-fp.ll' > '/dev/null' -- ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50 FAIL: LLVM :: ExecutionEngine/test-loadstore.ll (3205 of 6030) ******************** TEST 'LLVM :: ExecutionEngine/test-loadstore.ll' FAILED ******************** Script: -- /nfs_home/chenwj/test/native-build/arm2/Debug+Asserts/bin/lli /nfs_home/chenwj/test/llvm/test/ExecutionEngine/test-loadstore.ll > /dev/null -- Exit Code: 134 Co...

...-CondCode-Failure.ll LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll LLVM :: ExecutionEngine/hello.ll LLVM :: ExecutionEngine/hello2.ll LLVM :: ExecutionEngine/stubs.ll LLVM :: ExecutionEngine/test-call.ll LLVM :: ExecutionEngine/test-fp.ll LLVM :: ExecutionEngine/test-loadstore.ll LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted LLVM-Unit :: ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStubStillCallable LLVM-Uni...

...3-08-21-EnvironmentTest.ll LLVM :: ExecutionEngine/MCJIT/2003-08-23-RegisterAllocatePhysReg.ll LLVM :: ExecutionEngine/MCJIT/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll LLVM :: ExecutionEngine/MCJIT/2005-12-02-TailCallBug.ll LLVM :: ExecutionEngine/MCJIT/2007-12-10-APIntLoadStore.ll LLVM :: ExecutionEngine/MCJIT/2008-06-05-APInt-OverAShr.ll LLVM :: ExecutionEngine/MCJIT/2010-01-15-UndefValue.ll LLVM :: ExecutionEngine/MCJIT/fpbitcast.ll LLVM :: ExecutionEngine/MCJIT/hello.ll LLVM :: ExecutionEngine/MCJIT/hello2.ll LLVM :: ExecutionEngine/MCJIT...

...code base, I found several references to auto_ptr that should be investigated. Most, if not all of them are in test cases. # Tests that reference auto_ptr llvm/test/CodeGen/X86/negate-add-zero.ll llvm/test/Transforms/DeadStoreElimination/2011-09-06-EndOfFunction.ll llvm/test/Transforms/MemCpyOpt/loadstore-sret.ll # Things that define their own auto_ptr llvm/tools/clang/test/Analysis/diagnostics/Inputs/include/report-issues-within-main-file.h llvm/tools/clang/test/Analysis/diagnostics/report-issues-within-main-file.cpp llvm/tools/clang/test/CodeGenCXX/2010-07-23-DeclLoc.cpp # clang-tidy bits that...

... LLVM :: ExecutionEngine/2005-12-02-TailCallBug.ll >    LLVM :: ExecutionEngine/hello.ll >    LLVM :: ExecutionEngine/hello2.ll >    LLVM :: ExecutionEngine/stubs.ll >    LLVM :: ExecutionEngine/test-call.ll >    LLVM :: ExecutionEngine/test-fp.ll >    LLVM :: ExecutionEngine/test-loadstore.ll >    LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction >    LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted >    LLVM-Unit :: > ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.EscapedLazyStu...

Hi all, I would like to propose a mechanism that would allow LLVM to fold null pointer checks into "nearby" memory operations, subject to runtime support. This is related to but not exactly the same as a proposal floated by Peter Collingbourne earlier [1]. The obvious use cases are managed languages like Java, C# and Go that require a null check on pointers before they're used in

...y barriers regarding the device side of the spec. There are several places where memory barriers are mentioned and these all are about the driver. Maybe they are omitted because they are implicit somehow? Please clarify. regards, Nikolay Nikolaev [1] https://www.freelists.org/post/luajit/Compiler-loadstore-barrier-volatile-pointer-barriers-in-general,1 [2] http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf - 8.2.3.7 > > Thanks, > > -- > MST

On Mon, Jun 18, 2012 at 04:56:53PM -0700, reed kotler wrote: > I don't see any tests in either test or test-suite for -use-mcjit. For ARM, we need to manually switch to use mcjit, say $ make check-all LIT_ARGS=--param=jit_impl=mcjit Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799

...gt; LLVM :: ExecutionEngine/MCJIT/2003-08-23-RegisterAllocatePhysReg.ll > LLVM :: > ExecutionEngine/MCJIT/2003-10-18-PHINode-ConstantExpr-CondCode-Failure.ll > LLVM :: ExecutionEngine/MCJIT/2005-12-02-TailCallBug.ll > LLVM :: ExecutionEngine/MCJIT/2007-12-10-APIntLoadStore.ll > LLVM :: ExecutionEngine/MCJIT/2008-06-05-APInt-OverAShr.ll > LLVM :: ExecutionEngine/MCJIT/2010-01-15-UndefValue.ll > LLVM :: ExecutionEngine/MCJIT/fpbitcast.ll > LLVM :: ExecutionEngine/MCJIT/hello.ll > LLVM :: ExecutionEngine/MCJIT/hello2.ll >...

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks, -- MST

Hi Nikolay, I poked at src/lib/virtio/virtq.lua a bit - I was surprised to find no explicit CPU memory barriers in the virtq implementation. These are typically required when using virtio on smp machines - the spec actually mention where barriers are necessary. Are the barriers implicit somehow for lua? I'd be curious to learn. Thanks, -- MST

.../2005-12-02-TailCallBug.ll >>    LLVM :: ExecutionEngine/hello.ll >>    LLVM :: ExecutionEngine/hello2.ll >>    LLVM :: ExecutionEngine/stubs.ll >>    LLVM :: ExecutionEngine/test-call.ll >>    LLVM :: ExecutionEngine/test-fp.ll >>    LLVM :: ExecutionEngine/test-loadstore.ll >>    LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JIT.GlobalInFunction >>    LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTests/JITTest.AvailableExternallyGlobalIsntEmitted >>    LLVM-Unit :: >> ExecutionEngine/JIT/Debug+Asserts/JITTest...

I don't see any tests in either test or test-suite for -use-mcjit. Are we not testing this yet? There are lots of other llc options. What is our plan for testing these?

Hi Philip, On 29 May 2014 17:03, Philip Reames <listmail at philipreames.com> wrote: > I have some reservations about this proposal. I don't have anything > particularly concrete, but the idea of supporting both LL/SC and atomicrwm > in the IR concerns me from a complexity perspective. Well, I'll start by saying my particular optimisation use case looks like it's not

...t have to learn about the special semantics for the new > > (load|store)_with_trap intrinsics to be effective. > > Good. This is a codegen feature. We can’t say that enough. If you really > cared about the best codegen this would be done in machine IR after > scheduling and target LoadStore opts. I agree, with the caveat above. Mid-level passes shouldn't actively break these intrinsics. > > This pass will have to be a profile-guided optimization pass for > > fundamental reasons: implicit null checks are a pessimization even if > > a small fraction of the imp...

...owerPC/tailcall1-64.ll LLVM : : CodeGen/PowerPC/tailcall1.ll LLVM : : CodeGen/PowerPC/tailcallpic1.ll LLVM : : CodeGen/PowerPC/varargs.ll LLVM : : CodeGen/PowerPC/vec_auto_constant.ll LLVM : : CodeGen/PowerPC/vec_br_cmp.ll LLVM : : CodeGen/PowerPC/vec_buildvector_loadstore.ll LLVM : : CodeGen/PowerPC/vec_misaligned.ll LLVM : : CodeGen/PowerPC/vec_splat_constant.ll LLVM : : DebugInfo/array.ll LLVM : : ExecutionEngine/2002-12-16-ArgTest.ll LLVM : : ExecutionEngine/2003-01-04-ArgumentBug.ll LLVM : : ExecutionEngine/2003-01-04-LoopTes...