search for: block_code

Displaying 6 results from an estimated 6 matches for "block_code".

2013 Jul 05
0
[LLVMdev] Enabling vectorization with LLVM 3.3 for a DSL emitting LLVM IR
On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some
2013 Jul 04
3
[LLVMdev] Enabling vectorization with LLVM 3.3 for a DSL emitting LLVM IR
Hi, Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some informations that are needed by the vectorization passes to
2013 Jul 05
0
[LLVMdev] Enabling vectorization with LLVM 3.3 for a DSL emitting LLVM IR
...1 %27 = icmp slt i32 %next_index, %16 br i1 %27, label %code_block8, label %exec_block4.exit_block6_crit_edge exec_block.return_crit_edge: ; preds = %exit_block6 br label %return return: ; preds = %exec_block.return_crit_edge, %block_code ret void }
2013 Jul 05
2
[LLVMdev] Enabling vectorization with LLVM 3.3 for a DSL emitting LLVM IR
Le 5 juil. 2013 à 04:11, Tobias Grosser <tobias at grosser.es> a écrit : > On 07/04/2013 01:39 PM, Stéphane Letz wrote: >> Hi, >> >> Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be
2008 Nov 19
1
Question about updated block list history in the encoder
...frame is, but I'm sure there's a good one (perhaps it's to further refine the updated fragments). However, the way keyframes are handled in this history seems very counter-intuitive to me. When PrevFragments is initialized in ScanYUVInit(), PrevFragments[PrevFrameLimit-1] is set to BLOCK_CODED, which, although pointed out in the comments would be what you would expect for the very first keyframe if YUVAnalyseFrame() was called when coding the first keyframe, I would argue that PrevFragments[1] should have been set instead. In either case this seems odd to me, as it would appear to...
2013 Jul 05
2
[LLVMdev] Enabling vectorization with LLVM 3.3 for a DSL emitting LLVM IR
...t_index, %16 > br i1 %27, label %code_block8, label %exec_block4.exit_block6_crit_edge > > exec_block.return_crit_edge: ; preds = %exit_block6 > br label %return > > return: ; preds = %exec_block.return_crit_edge, %block_code > ret void > } > 1) "entry" block is the first block of the function right? 2) do you mean *all* "alloca" in a function always have to be in the fist entry block? Thanks. Stéphane