search for: rlwimi

...r/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/s4addl.ll: NODE: 0x8582300: i32,ch = CopyFromReg 0x8582240:1, 0x8582280 Abort trap (core dumped) Running /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/PowerPC/dg.exp ... FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/PowerPC/rlwimi.ll: Output/rlwimi.ll.out.script: cannot open rlwimi.ll: No such file or directory llc: bytecode didn't read correctly. Output/rlwimi.ll.out.script: cannot open rlwimi.ll: No such file or directory llc: bytecode didn't read correctly. FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Cod...

...able to handle many more strange target features. X. Andrew added initial JIT support to the Alpha backend, which can run some simple programs. It is not fully complete yet though. X. Jim Laskey contributed patches to improve the instruction selection in the PowerPC backend, matching more RLWIMI cases for example. X. Nate implemented most of the PowerPC DAG-to-DAG instruction selector. X. The tblgen tool & code generator now have more assertions and checking, which catch errors early, making it easier to work on the backend. X. The default register allocator is now far faster on so...

Chris Lattner wrote: > On Thu, 2 Dec 2004, Brent Monroe wrote: > >>I'm trying to add the xadd instruction to the X86 back end. >>xadd r/m32, r32 >>exchanges r/m32 and r32, and loads the sum into r/m32. I'm >>interested in the case where the destination operand is a >>memory location. >> >>I've added the following entry to

...more strange target features. > X. Andrew added initial JIT support to the Alpha backend, which can run > some simple programs. It is not fully complete yet though. > X. Jim Laskey contributed patches to improve the instruction selection in > the PowerPC backend, matching more RLWIMI cases for example. > X. Nate implemented most of the PowerPC DAG-to-DAG instruction selector. > X. The tblgen tool & code generator now have more assertions and checking, > which catch errors early, making it easier to work on the backend. > X. The default register allocator is...

...LangRef document: http://llvm.cs.uiuc.edu/docs/LangRef.html#constants Target Specific Code Generator Improvements: 19. Misha implemented the machine code emitter for the PowerPC target. 20. Nate substantially improved instruction selection in the PowerPC backend, allowing it to generate rlwimi, rlwinm, and other instructions. 21. Jeff Cohen contributed patches to allow the X86 backend to fold the addresses of globals more aggressively into X86 memory references. 22. John contributed a patch to the C backend to make it emit code that has fewer dynamic copies for PHI nodes,...

...uments/retvals in registers according to the Darwin ABI. *. Nate changed the PPC JIT to generate code in using the static relocation model instead of "dynamic-no-pic", since the JIT knows exactly where all code is located. *. Nate implemented a new, more aggressive, PPC rlwimi pattern matcher, which allows LLVM to produce much better code for bitfield operations in some cases. Compiler Cleanups, Speedups, and Code Size Reductions: *. The JIT code emitter (and thus the JIT) is much faster than before (PR469). *. Jim, Evan and I made several changes to red...

...nows about many more strange target features. 14. Andrew added initial JIT support to the Alpha backend, which can run some simple programs. It is not fully complete yet, though. 15. Jim Laskey contributed patches to improve the instruction selection in the PowerPC backend, matching more RLWIMI cases, for example. 16. Nate implemented most of the PowerPC DAG-to-DAG instruction selector. 17. The tblgen tool & code generator now have more assertions and checking, which catch errors early, making it easier to work on the backend. 18. The default register allocator is now far fa...

...s according to the Darwin ABI. 29. Nate changed the PPC JIT to generate code using the static relocation model instead of "dynamic-no-pic", since the JIT knows exactly where all globals are located when it is generating code. 30. Nate implemented a new, more aggressive, PPC rlwimi pattern matcher, which allows LLVM to produce much better code for bitfield operations in some cases. Compiler Cleanups, Speedups, and Code Size Reductions: 31. The JIT code emitter (and thus the JIT) is much faster than before (http://llvm.org/PR469). 31. Jim, Evan, and I made se...

...: CodeGen/PowerPC/indirectbr.ll LLVM : : CodeGen/PowerPC/int-fp-conv-0.ll LLVM : : CodeGen/PowerPC/int-fp-conv-1.ll LLVM : : CodeGen/PowerPC/lsr-postinc-pos.ll LLVM : : CodeGen/PowerPC/ppc32-vaarg.ll LLVM : : CodeGen/PowerPC/ppcf128-4.ll LLVM : : CodeGen/PowerPC/rlwimi-keep-rsh.ll LLVM : : CodeGen/PowerPC/rlwimi3.ll LLVM : : CodeGen/PowerPC/select-cc.ll LLVM : : CodeGen/PowerPC/shift128.ll LLVM : : CodeGen/PowerPC/stack-protector.ll LLVM : : CodeGen/PowerPC/tailcall1-64.ll LLVM : : CodeGen/PowerPC/tailcall1.ll LLVM : : Co...

On Thu, Jan 19, 2017 at 9:17 AM, Rackover, Zvi <zvi.rackover at intel.com> wrote: > Hi Sanjay, > > > > I agree we should also discuss **if** this canonicalization is beneficial. > > For starters, do we have a concrete case where we would benefit from > canonicalizing shuffles <-> truncates in LLVM IR? > > IMO, we should not count benefits for codegen