similar to: [LLVMdev] A strange testing case of SROA

Hi Shuxin I think i might have written that test. And yeah, no matter what values you get you’ll get a 0.0. Its probably a bad test case, but i can’t remember if it exposed a bug in this form or not. Since writing it Chandler rewrote SROA anyway so the original bug is long gone. Thanks, Pete On Apr 5, 2013, at 11:57 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, > >

Hi, Duncan: Thank you for sharing this info. I will check and go back to you next Monday. In case PR15674 is caused by the same bug, I will put a comment over there and close it. Thank you again! Shuxin On 4/6/13 2:55 AM, Duncan Sands wrote: > Hi Shuxin, > >> Following is excerpted from dynamic-vector-gep.ll. >> The resulting "extractelement" seems to

Hi Shuxin, > Following is excerpted from dynamic-vector-gep.ll. > The resulting "extractelement" seems to always return 0.0f regardless the value > idx1 and idx2 is holding. > Am I missing something here or there is something fishy take place? maybe this is the same as PR15674. Ciao, Duncan.

For the gep: %idx1 = getelementptr i32* %MyVar, i32 0 i32* is the type that MyVar is pointing to and i32 is the type of the offset value, or what? If it's the type of offset value, then the size of the pointer shouldn't be less than i32, correct? The index is 0, so in this example, the address computation is idx1 = &MyVar+0. What I want to know is the size in bits of the values

On Mon, Dec 12, 2011 at 3:54 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > For the gep: > > %idx1 = getelementptr i32* %MyVar, i32 0 > > i32* is the type that MyVar is pointing to and i32 is the type of the offset > value, or what? If it's the type of offset value, then > the size of the pointer shouldn't be less than i32, correct? > > > The index is

Hi, Here is a patch that adds the possibility of displaying key fingerprints in the bubblebabble format used by ssh.com ssh implementations. I hope it makes its way into the source. --- ./openssh-2.5.1/key_original.h Sun Mar 4 00:47:55 2001 +++ ./openssh-2.5.1/key.h Sun Mar 4 00:57:57 2001 @@ -36,6 +36,17 @@ KEY_DSA, KEY_UNSPEC }; + +enum digest_type { + DIGEST_TYPE_SHA1, +

Hi all, I'm having trouble understanding how llvm determines if pointers alias. Consider the following two functions that each do a redundant load: define float @A(float * noalias %ptr1) {   %ptr2 = getelementptr float* %ptr1, i32 1024   %val1a = load float* %ptr1   store float %val1a, float* %ptr2   %val1b = load float* %ptr1   ret float %val1b } define float @B(float * noalias %ptr1,

Thanks for your reply. After I change Cstr to gI, it compiled successfully. Thanks again. Another question is for constructing getelementpt. // C code char gStrA[10] = "test str"; // here is Global variable,gStrA and initializer "test str" char gStrB[10]= "test str2"; main(){ int = i; char *pGVars[20]; // here, the pGVar is for storing the address of each

On Fri, Oct 7, 2011 at 2:15 PM, andrew adams <andrew.b.adams at gmail.com> wrote: > Hi all, > > I'm having trouble understanding how llvm determines if pointers > alias. Consider the following two functions that each do a redundant > load: > > define float @A(float * noalias %ptr1) { >   %ptr2 = getelementptr float* %ptr1, i32 1024 >   %val1a = load float*

quite some speed improvement indeed. attached the updated patch to apply to svn/trunk. j -------------- next part -------------- A non-text attachment was scrubbed... Name: theora-mmx.patch.gz Type: application/x-gzip Size: 8648 bytes Desc: not available Url : http://lists.xiph.org/pipermail/theora-dev/attachments/20040824/5a5f2731/theora-mmx.patch-0001.bin

Hello, I've run into a problem which is both maddening and rather hard to replicate, therefore I wondered if someone might know of a plausible explanation for it. I couldn't find anything in the archives, though maybe I'm searching for the wrong thing. I'm calling some C code using .C, and get the vector I'm interested in back as the 7th location in the returned list.

----Snip-- struct st1{ int a; }; struct st2{ int b; }; struct st { struct st1 obj1; struct st2 obj2; }Obj; int test1(struct st1 * ptr1 , struct st2 * ptr2, struct st2 *ptr3) { ptr1->a = 10; *ptr3 = *ptr2; return ptr1->a; } --Snip--- For the above case GCC is able to store forward the value 10 to the return place. LLVM is not doing this. GCC https://godbolt.org/z/FCjCXy LLVM

The following is legal LLVM code in which ptr, ptr2, and ptr3 are all aliases: %struct = type { int, int } implementation int %p() { %ptr1 = alloca %struct %ptr2 = getelementptr %struct* %ptr1 %ptr3 = getelementptr %struct* %ptr2, uint 0 %pint = getelementptr %struct* %ptr3, uint 0, ubyte 0 %rval = load int* %pint ret int %rval } Should our pass a) ignore this, not replace %ptr1,

Hello everyone, In December, I had started a thread on scoped no-alias metadata in order to represent C99 'restrict' pointer information at the IR level: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056586.html At this point, we also have another important use case: preserving the existing 'noalias' attributes on pointers after inlining. My original proposal was

Dear all I have a function in which I would like to change some values to NA according to some condition. dropout<-function(y, nahr=FALSE,...) { <some stuff for computing an index> if (nahr) y[index]<<-NA invisible(index) } in case y is a vector all works OK but if it is a part of data frame by calling dropout(df$y) or dropout(df[,number]) no change is done. Please can you

Hello again, When I had originally discussed this proposal, it was thought that we would not have to worry about control dependencies on the noalias metadata because such dependencies could only present a problem when loads or stores are merged (RAUW is called), and transformations should drop metadata when that happens. Now I'm worried that this is not true. Here's a simple example:

Hi Danny, Thanks for that :) However I've just updated the prototype patch to NewGVN and it didn't need any API changes - all I rely on is GVNExpression. Hongbin, I wanted to explain a little about what GVNSink can currently do, what it was designed for and hopefully how to make it handle your testcase. *Background* Common code sinking is more difficult to efficently do than one might

It seems the same bug is there if we do pointer swapping with selects. Do you agree? (see example below) define void @f() { entry: %a1 = alloca float, align 4 %a2 = alloca float, align 4 br label %loop end: ret void loop: %phi = phi i32 [ 0, %entry ], [ 1, %loop ] %select_cond = icmp eq i32 %phi, 0 %ptr1 = select i1 %select_cond, float* %a1, float* %a2 %ptr2 = select i1

Hi again, thanks a lot for the quick answer. I just forgot the comma, always these stupid mistakes... Anyways, as I said before, I have two data.frames containing about 1000 rows and I would like to avoid looping through all of them... In each data.frame are coordinates (x,y,z), so every row is giving the information on one single point. I would like to calculate the distance from each point

Hi Matthijs, Sorry for not responding earlier. I have a few comments. On Aug 7, 2008, at 7:41 AM, Matthijs Kooijman wrote: > Hi Mon Ping, > > I've again attached a patch, wich lets LLVM know about about the > relations > between different address spaces. Instead of cramming this info in > with > TargetData (with all kinds of unwanted side effects, especially for