Displaying 6 results from an estimated 6 matches for "block_cod".
Did you mean:
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