Displaying 19 results from an estimated 19 matches for "gep1".
Did you mean:
gep
2015 Jun 18
3
[LLVMdev] problem with replacing an instruction
...; U : I.operands()) {
Value* V = U.get();
if (!dyn_cast<Instruction>(V)) {
// must be a function's argument
std::vector<llvm::Value*> vect_1;
vect_1.push_back(Builder->getInt64(0));
llvm::GetElementPtrInst* gep1 =
llvm::GetElementPtrInst::Create(V, ArrayRef< Value * >(vect_1) );
BB.getInstList().insert(&I, gep1);
llvm::BitCastInst *bci = new BitCastInst (gep1,
BCI->getDestTy() );
llvm::ReplaceInstWithInst( &I , bci );
}
}
}...
2016 Jul 25
3
Alias Analysis with inbound GEPs
Hi,
I'm checking aliasing of two pointers:
%GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39
%GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16
The result I got is "PartialAlias" because the indices of the GEP1 are variable. Shouldn't the "inbounds...
2016 Jul 25
2
Alias Analysis with inbound GEPs
I’m checking aliasing of two pointers:
%GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39
%GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16
The result I got is “PartialAlias” because the indices of the GEP1 are variable.
That seems like a bug. PartialAlias should...
2016 Jul 26
2
Alias Analysis with inbound GEPs
...emikhovsky" <llvm-dev at lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, July 25, 2016 9:45:55 AM
> Subject: [llvm-dev] Alias Analysis with inbound GEPs
>
> Hi,
>
> I’m checking aliasing of two pointers:
>
> %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39
> %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16
>
> The result I got is “PartialAlias” because the indices of the GEP1 are variable.
> That seems like a bug...
2016 Jul 25
4
Alias Analysis with inbound GEPs
...gt;>
>>> Sent: Monday, July 25, 2016 2:46:34 PM
>>> Subject: RE: [llvm-dev] Alias Analysis with inbound GEPs
>>>
>>>
>>>>
>>>> I’m checking aliasing of two pointers:
>>>>
>>>>
>>>>
>>>> %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 1, i64 %indvars.iv41, i64 %indvars.iv39
>>>>
>>>> %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0, i32 16
>>>>
>>>>
>>>>
>>>> The result I got is “P...
2016 Jul 26
2
Alias Analysis with inbound GEPs
...6:34 PM
> >>> Subject: RE: [llvm-dev] Alias Analysis with inbound GEPs
> >>>
> >>>
> >>>>
> >>>> I’m checking aliasing of two pointers:
> >>>>
> >>>>
> >>>>
> >>>> %GEP1 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0,
> >>>> i32 1, i64 %indvars.iv41, i64 %indvars.iv39
> >>>>
> >>>> %GEP2 = getelementptr inbounds %struct.s, %struct.s* %0, i64 0,
> >>>> i32 16
> >>>>
> >>...
2010 Sep 07
2
[LLVMdev] loop fusion
...t;
[#uses=2]
br label %loop
loop: ; preds = %loop,
%bb.nph12
%indvar13 = phi i64 [ 0, %bb.nph12 ], [ %indvar.next14, %loop ] ;
<i64> [#uses=3]
%gep = getelementptr [16 x float]* %ret, i64 0, i64 %indvar13 ;
<float*> [#uses=1]
%gep1 = getelementptr [16 x float]* %0, i64 0, i64 %indvar13 ;
<float*> [#uses=1]
%load = load float* %gep ; <float> [#uses=1]
store float %load, float* %gep1
%indvar.next14 = add i64 %indvar13, 1 ; <i64> [#uses=2]
%exitcond15 = icmp eq i64...
2013 Nov 23
2
[LLVMdev] GVN fails with bitcasts
Hi,
i have the following code:
define internal %"struct.dexter::ConditionConstant"*
@_ZN6dexter18BinaryConditionAdd8evaluateEv5(%"class.dexter::BinaryConditionAdd"*)
{
entry:
%1 = getelementptr inbounds %"class.dexter::BinaryConditionAdd"* %0, i32
0, i32 0, i32 1
%2 = load %"class.dexter::BaseCondition"** %1, align 8
%3 = bitcast
2012 Feb 16
0
[LLVMdev] Wrong AliasAnalysis::getModRefInfo result
...; I != E; ++I)
{
Instruction *Inst = &*I;
if ( GetElementPtrInst *gep = dyn_cast<GetElementPtrInst>(Inst) )
geps.push_back(gep);
}
}
errs() << "List of GEPs:\n";
for(std::list<GetElementPtrInst* >::iterator itGep1
= geps.begin(); itGep1 != geps.end(); itGep1++){
GetElementPtrInst *gep1 = *itGep1;
Type *t1 = ((PointerType *)gep1->getType())->getElementType();
int64_t size1 = TD.getTypeAllocSize(t1);
std::list<GetElementPtrInst* >::iterator itGep2 = itGep...
2012 Feb 15
2
[LLVMdev] Wrong AliasAnalysis::getModRefInfo result
Just want to test out the LLVM's AliasAnalysis::getModRefInfo API. The
input C code is very simple:
void foo(int *a, int *b)
{
for(int i=0; i<10; i++)
b[i] = a[i]*a[i];
}
int main()
{
int a[10];
int b[10];
for(int i=0; i<10; i++)
a[i] = i;
foo(a,b);
return 0;
}
Obviously, for "foo", it only reads from array "a" and only writes to array
2020 Mar 23
3
[InstCombine] Addrspacecast and GEP assumed commutative
...i16 addrspace(1)*
> %gep = getelementptr i16, i16 addrspace(1)* %asc, i64 16
> store i16 0, i16 addrspace(1)* %gep, align 16
>
> ret void
> }
>
> opt -instcombine transforms this to:
>
> define void @test(i64 %0) {
> %ptr = inttoptr i64 %0 to i16*
>
> %gep1 = getelementptr i16, i16* %ptr, i64 16
> %gep = addrspacecast i16* %gep1 to i16 addrspace(1)*
> store i16 0, i16 addrspace(1)* %gep, align 16
>
> ret void
> }
>
> As you can see, the order of the GEP and addrspacecast is changed.
> Is this the expected behaviour? Norma...
2010 Sep 07
0
[LLVMdev] loop fusion
...gt;
[#uses=2]
br label %loop
loop: ; preds = %loop, %bb.nph12
%indvar13 = phi i64 [ 0, %bb.nph12 ], [ %indvar.next14, %loop ] ;
<i64> [#uses=3]
%gep = getelementptr [16 x float]* %ret, i64 0, i64 %indvar13 ;
<float*> [#uses=1]
%gep1 = getelementptr [16 x float]* %0, i64 0, i64 %indvar13 ;
<float*> [#uses=1]
%load = load float* %gep ; <float> [#uses=1]
store float %load, float* %gep1
%indvar.next14 = add i64 %indvar13, 1 ; <i64> [#uses=2]
%exitcond15 = icmp eq i64...
2010 Sep 08
0
[LLVMdev] loop fusion
...loop: ; preds = %loop,
> %bb.nph12
> %indvar13 = phi i64 [ 0, %bb.nph12 ], [ %indvar.next14, %loop ] ;
> <i64> [#uses=3]
> %gep = getelementptr [16 x float]* %ret, i64 0, i64 %indvar13 ;
> <float*> [#uses=1]
> %gep1 = getelementptr [16 x float]* %0, i64 0, i64 %indvar13 ;
> <float*> [#uses=1]
> %load = load float* %gep ;<float> [#uses=1]
> store float %load, float* %gep1
> %indvar.next14 = add i64 %indvar13, 1 ;<i64> [#uses=2]
>...
2014 Mar 13
2
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
...(LA.getValueAsString(),
> RA.getValueAsString()))
> + return Res;
> + break;
> + }
>
> Attributes already have operator< and operator==. Please reuse them.
>
> 0006:
>
> This looks fine.
>
> 0007:
>
> + int cmpGEP(const GEPOperator *GEP1, const GEPOperator *GEP2);
> + int cmpGEP(const GetElementPtrInst *GEP1,
> + const GetElementPtrInst *GEP2) {
>
> Const members?
>
> + unsigned BitWidth = DL ? DL->getPointerSizeInBits(AS1) : 1;
> + APInt Offset1(BitWidth, 0), Offset2(BitWidth, 0);
> + if...
2011 Oct 19
0
[LLVMdev] Question regarding basic-block placement optimization
...ake it out.
Still, for the test cases that don't tickle the iteration bug, it generates
beautiful, well laid out code. =]
% cat ifchain.ll
; RUN: opt < %s -analyze -block-freq | FileCheck %s
declare void @error(i32 %i, i32 %a, i32 %b)
define i32 @test(i32 %i, i32* %a, i32 %b) {
entry:
%gep1 = getelementptr i32* %a, i32 1
%val1 = load i32* %gep1
%cond1 = icmp ugt i32 %val1, 1
br i1 %cond1, label %then1, label %else1, !prof !0
then1:
call void @error(i32 %i, i32 1, i32 %b)
br label %else1
else1:
%gep2 = getelementptr i32* %a, i32 2
%val2 = load i32* %gep2
%cond2 = icmp...
2014 Jan 21
3
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
...n cause a
correctness problem? I.e., what am I missing here?
I also have a few low-level comments (and nitpicks):
- The comments at the top of the file don't match the new implementation!
- Lots of strange tabbing after your changes. E.g.:
+ int cmpGEP(const GetElementPtrInst *GEP1,
const GetElementPtrInst *GEP2) {
- After the FunctionPtr class declaration, you have an extra blank line. There
are a few of these scattered through (e.g., at the beginning of
FunctionComparator::cmpConstants).
- Your new helper functions (such as cmpNumbers)...
2011 Oct 19
3
[LLVMdev] Question regarding basic-block placement optimization
On Tue, Oct 18, 2011 at 6:58 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote:
>
> On Oct 18, 2011, at 5:22 PM, Chandler Carruth wrote:
>
> As for why it should be an IR pass, mostly because once the selection dag
>> runs through the code, we can never recover all of the freedom we have at
>> the IR level. To start with, splicing MBBs around requires known about
2014 Feb 27
3
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
Hi Nick,
I tried to rework changes as you requested. One of patches (0004 with
extra assertions) has been removed.
> + bool isEquivalentType(Type *Ty1, Type *Ty2) const {
> + return cmpType(Ty1, Ty2) == 0;
> + }
>
> Why do we still need isEquivalentType? Can we nuke this?
Yup. After applying all the patches isEquivalentType will be totally
replaced with cmpType. All
2014 Jan 17
6
[LLVMdev] MergeFunctions: reduce complexity to O(log(N))
Hi all,
I propose simple improvement for MergeFunctions pass, that reduced its
complexity from O(N^2) to O(log(N)), where N is number of functions in
module.
The idea, is to replace the result of comparison from "bool" to
"-1,0,1". In another words: define order relation on functions set.
To be sure, that functions could be comparable that way, we have to
prove that order