search for: c1_i

Displaying 9 results from an estimated 9 matches for "c1_i".

Did you mean: c1_2
2012 Oct 25
2
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
> > PHIElim and TwoAddress passes leave SSA form. > May be a missed something in your code but %vreg48 seems to be there > after PHI elimination. PHIElim tags those kind of registers as being > PHIJoin regs, updating LiveVariables pass, so the regcoalescer is aware > of them (some SSA info is still alive but the reg coalescer will > invalidate that information after
2007 Aug 23
1
Expedite scalar f(x) evaluation over vectors
...{ sapply(y, function(y) { integrate(function(x) {a*(c1+x)+b*(c2+x)}, boundsx[1], boundsx[2])$value }) }, boundsy[1],boundsy[2]) } I would like to rapidly evaluate this function over vectors c1 and c2 of equal length where the double integral is calculated for each (matching) element c1_i & c2_i. At present I get length mismatch errors. Furthermore, mapply() takes too long. Can I expedite this evaluation or do I need to reformulate my approach? Thanks in advance for your help, Scott C. Stark University of Arizona [[alternative HTML version deleted]]
2012 Oct 25
0
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. If I look at the : %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 instructions ; it gets joined to : 928B%vreg34<def> = COPY %vreg48:sel_y;  when vreg6 and vreg48 are joined. It's right. But joining the following copy 
2012 Oct 25
0
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
Hi Vincent, On 24/10/2012 23:26, Vincent Lejeune wrote: > Hi, > > I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. > > The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : > > // BEFORE LOOP >
2012 Oct 24
3
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
Hi, I don't know if my llvm ir code is faulty, or if I spot a bug in the RegisterCoalescing Pass, so I'm posting my issue on the ML. Shader and print-before-all dump are given below. The interessing part is the vreg6/vreg48 reduction : before RegCoalescing, the machine code is : // BEFORE LOOP ... Some COPYs.... 400B%vreg47<def> = COPY %vreg2<kill>; R600_Reg32:%vreg47,%vreg2
2012 Oct 25
0
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. vreg10 only appears in BB#3, and the join only occurs in BB#3 apparently even if vreg32 lives in the 4 machine blocks After joining, there
2012 Oct 25
3
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
Hi Vincent, On 25/10/2012 18:14, Vincent Lejeune wrote: > When examining the debug output of regalloc, it seems that joining 32bits reg also joins 128 parent reg. > > If I look at the : > %vreg34<def> = COPY %vreg6:sel_y; R600_Reg32:%vreg34 R600_Reg128:%vreg6 > > instructions ; it gets joined to : > 928B%vreg34<def> = COPY %vreg48:sel_y; > > when vreg6 and
2012 Oct 26
1
[LLVMdev] RegisterCoalescing Pass seems to ignore part of CFG.
Vincent, File a bug report so you can get a fix for it. Ivan On 25/10/2012 23:01, Vincent Lejeune wrote: > Thank for your help. You're right, merging vreg32 and vreg48 is perfectly fine, sorry I missed that. > I "brute force" debuged by adding MachineFunction dump after each join, I think I found the issue : it's when vreg32 and vreg10 are merged. > vreg10 only
2007 Aug 23
1
Clarification: Expedite scalar f(x) evaluation over vectors
...(x,y)}, boundsx[1], boundsx[2])$value }) }, boundsy[1],boundsy[2]) } <<I do not have a closed form for the real function>> I would like to rapidly evaluate this function over vectors c1 and c2 of equal length where the double integral is calculated for each (matching) element c1_i & c2_i. At present I get length mismatch errors. Furthermore, mapply() takes too long. Can I expedite this evaluation or do I need to reformulate my approach? Thanks in advance for your help, Scott C. Stark University of Arizona [[alternative HTML version deleted]]