Displaying 9 results from an estimated 9 matches for "storesize".
2014 Jan 08
3
[LLVMdev] reference to non-static member function must be called
...PointerType::getUnqual(Int8Type);
Type* VoidType = Type::getVoidTy(M->getContext());
DataLayout *TD = &getAnalysis<DataLayout>();
Value *Pointer = SI.getPointerOperand();
Pointer = castTo(Pointer,VoidPtrType,Pointer->getName(),&SI);
uint64_t size = TD->getTypeStoreSize(SI.getOperand(0)->getType());
Value *StoreSize = ConstantInt::get(Int32Type, size);
std::vector<Value *> args;
args.push_back(StoreSize);
args.push_back(Pointer);
args.push_back(0);
Instruction *inst = CallInst::Create(print,args,"",&SI);
}
while compili...
2013 Jan 02
0
[LLVMdev] [DragonEgg] [Polly] Should we expect DragonEgg to produce identical LLVM IR for identical GIMPLE?
...7802368
offset = 16, value = 64
offset = 20, value = 64
offset = 24, value = 64
MemoryAccess 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 472478...
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
2014 Sep 04
2
[LLVMdev] How to deal with wider Integer type?
Hi,
I am currently working on an opencl project based on LLVM, the target
device is 32bit.
I met a problem that some llvm passes like GVN SROA will generate some IR
operating
on wide integer types like i128 or i512. But the device does not support
such kind of data type.
Is there any idea on how to lower this kind of IR to only operate on i32 or
vector of i32? Or is there any existing code handle
2014 Sep 04
2
[LLVMdev] How to deal with wider Integer type?
...Instruction *InsertPt,
const DataLayout &DL) {
....
// Convert vectors and fp to integer, which can be manipulated.
if (!StoredValTy->isIntegerTy()) {
StoredValTy = IntegerType::get(StoredValTy->getContext(), StoreSize);
StoredVal = new BitCastInst(StoredVal, StoredValTy, "", InsertPt);
}
...
here if LoadedTy is Vector type like <4 x i32>, then StoreSize will be 128
bit integer.
I will show you some example later.
I find in pass ScalarReplAggregates it offers some configuration parameters
t...
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?)
...alue = 64
> offset = 20, value = 64
> offset = 24, value = 64
> MemoryAccess 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] -> M...
2006 Dec 19
3
[LLVMdev] alias-aware scheduling
...;
+ } else {
+ assert(0 && "FindAliasInfo expected a memory operand");
+ }
+
+ return false;
+ }
+
+ /// getStoreRoot - Return a virtual root for a store to a specified address.
+ ///
+ SDOperand getStoreRoot(SDOperand StoreAddr,
+ int64_t StoreSize,
+ const Value *StoreAddrValue,
+ int StoreOffset) {
+ // The special behavior may be disabled by an option.
+ if (!SchedulerMemoryDisambiguation)
+ return getRoot();
+
+ std::vector<SDOperand> DependentMemOps, IndependentMemOps;
+...
2020 Jun 10
2
LoopStrengthReduction generates false code
....iv, 8
br i1 %cmp, label %while.body, label %while.end
; Exit blocks
while.end: ; preds = %while.body
store volatile i32 %0, i32* %result, align 4, !tbaa !2
ret void
I guess "%uglygep = getelementptr.." will be lowered to @buffer + (%lsr.iv * StoreSize(i32)). That's what I see in the final code. But then %lsr.iv.next should be incremented by 1; BUT it is incremented by 8.
Incrementing %lsr.iv.next by 8 would make sense if getelementptr were lowered to @buffer + %lsr.iv.
Thanks for your help,
Boris
> Am 09.06.2020 um 21:56 schrieb Eli...
2020 Jun 09
2
LoopStrengthReduction generates false code
Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal.
Boris
> Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>:
>
> Blindly guessing here,