Displaying 3 results from an estimated 3 matches for "256i1".
Did you mean:
2561
2013 Jan 02
0
[LLVMdev] [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?
...Access to pointer: float* inttoptr (i64 47246749696 to float*)
{ Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47246749696 to
float*)[4096i0 + 64i1 + i2] }
allocSize: 4 storeSize: 4
replacedBy: { Stmt__12_cloned_[i0, i1, i2] -> NULL[o0] : o0 >=
47246749696 + 16384i0 + 256i1 + 4i2 and o0 <= 47246749699 + 16384i0 + 256i1
+ 4i2 }
MemoryAccess to pointer: float* inttoptr (i64 47247802368 to float*)
{ Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47247802368 to
float*)[4096i0 + 64i1 + i2] }
allocSize: 4 storeSize: 4
replacedBy: { Stmt__12_cloned...
2013 Jan 02
2
[LLVMdev] [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?
On 01/01/2013 02:45 PM, Duncan Sands wrote:
> Hi Dmitry,
>
>>
>> In our compiler we use a modified version LLVM Polly, which is very
>> sensitive to
>> proper code generation. Among the number of limitations, the loop region
>> (enclosed by phi node on induction variable and branch) is required to
>> be free
>> of additional memory-dependent
2013 Jan 04
4
[LLVMdev] [Polly] Aliasing problems escalation (WAS: Re: [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?)
...inttoptr (i64 47246749696 to float*)
> { Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47246749696 to
> float*)[4096i0 + 64i1 + i2] }
> allocSize: 4 storeSize: 4
> replacedBy: { Stmt__12_cloned_[i0, i1, i2] -> NULL[o0] : o0 >=
> 47246749696 + 16384i0 + 256i1 + 4i2 and o0 <= 47246749699 + 16384i0 + 256i1
> + 4i2 }
> MemoryAccess to pointer: float* inttoptr (i64 47247802368 to float*)
> { Stmt__12_cloned_[i0, i1, i2] -> MemRef_nttoptr (i64 47247802368 to
> float*)[4096i0 + 64i1 + i2] }
> allocSize: 4 storeSize: 4
>...