search for: gepis

Displaying 20 results from an estimated 29 matches for "gepis".

Did you mean: geis
2005 Jul 29
0
[LLVMdev] patch for pointer-to-array conversion
The enlosed patch for IndVarSimplify.cpp works even when the pointer increment is deeply nested wrt pointer initialization, but note that it needs to have loop structures preserved, as in the following: int A[3000000], B[20000], C[100], Z; volatile int I, J, K; int main() { int i, j, k, *a, *b, *c; for ( a = &A[0], i = 0; i != 300; i++ ) { I++;
2009 May 14
2
[LLVMdev] Fusing GEPIs
Hi, Is there any standard pass or something that can fuse chained GEPIs? I.e. turning b = getelementptr a, 10, 1 c = getelementptr b, 0, 3 d = getelementptr c, 0, 5 into: d = getelementptr a, 10, 1, 3, 5 In our case this would greatly simplify some analysis passes, at the moment we have to trace back a gepi-chain and extract all the indices manually (the origin...
2005 Jul 28
2
[LLVMdev] help with pointer-to-array conversion
I now understand that IndVarSimplify.cpp is capable of reproducing array references when the pointer initialization from the array address is found inside the immediately enclosing loop, such that in the following code: int A[20000], B[100], Z; int main() { int i, j, *a, *b; for ( a = &A[0], i = 0; i != 200; i++ ) for ( b = &B[0], j = 0; j != 100; j++
2010 May 05
2
[LLVMdev] How to cast an integer array to an integer pointer? (user question)
I am new to LLVM and couldn't find any llvm-user list, so I am posting my user question here, sorry. I am trying to create a simple "puts" call accepting the static string, with the code below. The last line (CallInst::Create) fails with an assert: "Calling a function with a bad signature!" Because the type of function is void(u8*) and the argument supplied is:
2008 Apr 29
0
[LLVMdev] [PATCH] use-diet for review
On Apr 29, 2008, at 1:27 AM, Gabor Greif wrote: > Hi all, > > I have reported more than enough about the space savings achieved > and the associated costs, here comes the current patch for review. > > Since this one is substantially smaller than the previous one, I did > not cut it in pieces. The front part is about headers and the rest > the .cpp and other files. Hi
2005 Jul 28
0
[LLVMdev] help with pointer-to-array conversion
On Thu, 28 Jul 2005, Naftali Schwartz wrote: > I now understand that IndVarSimplify.cpp is capable of reproducing array > references when the pointer initialization from the array address is found > inside the immediately enclosing loop, such that in the following code: Ok. > int A[20000], B[100], Z; > int main() > { > int i, j, *a, *b; > for ( a =
2019 Mar 27
2
getelementptr inbounds with offset 0
Hi Johannes, > Now that reasoning works from a conceptual standpoint only for > non-inbounds GEPs, I think. From a practical standpoint my above > description will probably make sure everything works out just fine (see > also my rephrased answer down below!). I say this because I think the > following lang-ref passage makes sure everything, not only memory > accesses, involving
2019 Apr 10
2
getelementptr inbounds with offset 0
Hi, >>> I see. Is there a quick answer to the questions why you need inbounds >>> GEPs in that case? Can't you just use non-inbounds GEPs if you know you >>> might not have a valid base ptr and "optimize" it to inbounds once that >>> is proven? >> >> You mean on the Rust side? We emit GEPi for field accesses and array indexing.
2008 Apr 29
5
[LLVMdev] [PATCH] use-diet for review
Hi all, I have reported more than enough about the space savings achieved and the associated costs, here comes the current patch for review. Since this one is substantially smaller than the previous one, I did not cut it in pieces. The front part is about headers and the rest the .cpp and other files. Cheers, Gabor -------------- next part -------------- An embedded and charset-unspecified
2019 Mar 15
2
getelementptr inbounds with offset 0
Hi Johannes, > From the Lang-Ref statement > > "With the inbounds keyword, the result value of the GEP is undefined > if the address is outside the actual underlying allocated object and > not the address one-past-the-end." > > I'd argue that the actual offset value (here 0) is irrelevant. The GEP > value is undefined if inbounds is present and the
2008 Apr 04
2
[LLVMdev] InstCombine Question
I am confused by this bit of code in instcombine: 09789 if (GetElementPtrInst *GEPI = dyn_cast<GetElementPtrInst>(Op)) { 09790 const Value *GEPI0 = GEPI->getOperand(0); 09791 // TODO: Consider a target hook for valid address spaces for this xform. 09792 if (isa<ConstantPointerNull>(GEPI0) && 09793
2014 Dec 09
2
[LLVMdev] Question on equivalence of pointer types
> On Dec 8, 2014, at 5:12 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > Partially answering my own question, in general these are not > equivalent because LLVM allows for pointers in different address > spaces to have different sizes. However, are they equivalent if > pointers in addrspace(1) have the same size as pointers in > addrspace(0)? > >
2019 Mar 26
2
getelementptr inbounds with offset 0
Hi Johannes, >> So, the thinking here is: LLVM cannot exclude the possibility of an >> object of size 0 existing at any given address. The pointer returned >> by "GEPi p 0" then would be one-past-the-end of such a 0-sized object. >> Thus, "GEPi p 0" is the identitiy function for any p, it will not >> return poison. > > I don't see the
2011 Jan 22
2
[LLVMdev] Pointers in Load and Store
John, I have looked at the SAFECode and thought following sould work if (isa<Constant>(I.getOperand(0))) { Out << "*** operand 0 is a constant ******"; if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) { Out << "********operand is an instruction ****"; if (GetElementPtrInst *gepI =
2004 Nov 15
0
[LLVMdev] Fixes for windows version
Morten, I've applied these patches. Thanks for the updates! Reid. On Mon, 2004-11-15 at 01:26, Morten Ofstad wrote: > Hi, > > when I updated the sources today there were several small problems that > stopped the windows version from compiling, here are the patches > > m. > > > ______________________________________________________________________ > Index:
2004 Nov 15
2
[LLVMdev] Fixes for windows version
Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>
2014 Dec 05
3
[LLVMdev] Question on equivalence of pointer types
Is copy.0 semantically equivalent to copy.1 in the following example? define void @copy.0(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst) { entry: %val = load i8 addrspace(1)* addrspace(1)* %src store i8 addrspace(1)* %val, i8 addrspace(1)* addrspace(1)* %dst ret void } define void @copy.1(i8 addrspace(1)* addrspace(1)* %src, i8 addrspace(1)* addrspace(1)* %dst)
2011 Jan 22
0
[LLVMdev] Pointers in Load and Store
On 1/21/2011 10:46 PM, Surinder wrote: > John, > > I have looked at the SAFECode and thought following sould work > > if (isa<Constant>(I.getOperand(0))) > { Out<< "*** operand 0 is a constant ******"; > if (Instruction *operandI = dyn_cast<Instruction>(I.getOperand(0))) > { Out<<
2013 Nov 19
0
[R-pkgs] Introducing pedgene 1.2 on CRAN
Dear useRs: We would like to introduce the "pedgene" package, version 1.2, available now on CRAN, with a brief manual available as a vignette: http://cran.r-project.org/web/packages/pedgene/index.html The pedgene package performs gene-level kernel and burden association tests with disease status and continuous response for pedigree data, as described in our recent paper: Schaid, D.
2013 Nov 19
0
Introducing pedgene 1.2 on CRAN
Dear useRs: We would like to introduce the "pedgene" package, version 1.2, available now on CRAN, with a brief manual available as a vignette: http://cran.r-project.org/web/packages/pedgene/index.html The pedgene package performs gene-level kernel and burden association tests with disease status and continuous response for pedigree data, as described in our recent paper: Schaid, D.