similar to: [LLVMdev] Question about Alias Analysis

On Mon, 25 Jun 2007, Ben Chambers wrote: > I guess what confuses me is that it doesn't seem like it was able to > figure out that *b = a. Am I looking at this wrong? Is there a more > accurate way of getting the alias information out of the pass? The answer is to not look at the alias sets. I'd suggest looking at the raw results of alias queries. To do this, use the -aa-eval

Thanks, that's a lot more like the output I was expecting. But, I'm now wondering if I'm doing something wrong because the output confuses me. When run on the program: int main() { int a = 5; int* b = &a; int* c = &a; return *b; } I would expect to see either b may alias c or b must alias c. But, it doesn't even appear in the list. Furthermore, I would expect

hi, Dale Johannesen wrote: > On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: >> i'm trying to make some experiments with the ARM backend (llvm 2.1) >> and >> therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. >> >> however, the llvm-gcc frontend seems to cause troubles with single >> precision floating point values, i.e., they are

On Oct 19, 2007, at 7:23 AM, Dietmar Ebner wrote: > hi, > > i'm trying to make some experiments with the ARM backend (llvm 2.1) > and > therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. > > however, the llvm-gcc frontend seems to cause troubles with single > precision floating point values, i.e., they are not converted > correctly > to the

hi, i'm trying to make some experiments with the ARM backend (llvm 2.1) and therefore built an arm-softfloat-linux-gnu toolchain on x86_64 linux. however, the llvm-gcc frontend seems to cause troubles with single precision floating point values, i.e., they are not converted correctly to the particular target format (double precision works as expected). it seems the problem is related to

Oh m sorry for that mistake as I had points to in mind. But still what about the following prog: int main() { int *i,*j,k; i=&k; j=&k; k=4; printf("%d,%d,%d",*i,*j,k); return 0; } here too i dont get <i,j> alias each other. Duncan Sands wrote: > Hi ambika, > >> main() { >> int i,*k; >> k =

<div>Need help about Alias Analysis.</div><div>I try to detect use-after-free debug in source code. And my analysis is based on LLVM IR.</div><div>I use the following code as a small example. I want to get the result p&&q are alias.</div><div>//uaf.cpp</div><div><div>#include<iostream></div><div>using namespace

Hey Duncan, hey everybody else, I just stumbled upon a problem in the latest llvm-gcc trunk which is related to my previous problem with the 64bit ABI and structs: Given the following code: struct float3 { float x, y, z; }; extern "C" void __attribute__((noinline)) test(float3 a, float3* res) { res->y = a.y; } int main(void) { float3 a; float3 res; test(a,

On 01/28/2013 12:58 PM, Pekka Jääskeläinen wrote: > Hi, > > Attached is a patch which uses a simple "parallel_loop" metadata attached > to the loop branch instruction in the loop latch for skipping > cross-iteration > memory dependency checking in the LoopVectorizer. This was briefly > discussed > in the email thread "LoopVectorizer in OpenCL C work group

Hello, LLVM-Dev guys. I just wonder if function variables are preserved in the bytecode. For example, are i and j in the following function preserved in .bc? int sum(int i, int j){ int k; k = i + j; return k; } I tested this with "llc -march=c" and found this was converted to int sum(int ltmp_0_1, int ltmp_1_1) { return (ltmp_1_1 + ltmp_0_1); } Therefore, it seems

Hi, Attached is a patch which uses a simple "parallel_loop" metadata attached to the loop branch instruction in the loop latch for skipping cross-iteration memory dependency checking in the LoopVectorizer. This was briefly discussed in the email thread "LoopVectorizer in OpenCL C work group autovectorization". It also converts the "min iteration count to vectorize"

Hello everybody, unfortunately, I have some problems using the LLVM assembler parser ... - use llvm-gcc ( llvm-gcc -O0 -S --emit-llvm -o system2.ll system2.c) to translate the following small example into LLVM assembly language: int common_func1() { return 5; } int common_func2(int a) { return a + 5; } void Handler1() { int e = 4; int f = common_func1(); int ret = common_func2(e);

On 16 February 2010 20:49, Trevor Harmon <Trevor.W.Harmon at nasa.gov> wrote: > We were discussing that a few days ago: > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-February/029245.html Hi Trevor, On a similar question, I'd want to see what line is being compiled to which instructions. Is it possible to print the before the instructions as comment? For example:

On 25 Dec 2007, at 03:29, Gordon Henriksen wrote: > Hi Jo, > > On 2007-12-24, at 14:43, Joachim Durchholz wrote: > >> I'm in a very preliminary phase of a language project which requires >> some specific optimizations to be reasonably efficient. >> >> LLVM already looks very good; I'd just like to know whether I can >> push these optimizations

hi, i've got some more things to note. first, the issue is not related to x86_64 being the host machine - it also happens on i686/linux. next, i think (one of) the problem(s) is the use of [HOST_]WORDS_BIG_ENDIAN instead of [HOST_]FLOAT_WORDS_BIG_ENDIAN in llvm-convert.cpp (see patch below). this fixes single precision floating point but breaks double precision. for

On Jan 29, 2013, at 12:51 AM, Tobias Grosser <tobias at grosser.es> wrote: > > # ignore assumed dependences. > for (i = 0; i < 4; i++) { > tmp1 = A[3i+1]; > tmp2 = A[3i+2]; > tmp3 = tmp1 + tmp2; > A[3i] = tmp3; > } > > Now I apply for whatever reason a partial reg2mem transformation. > > float tmp3[1]; > > # ignore assumed

Hi R-users, I'm quite new to R and trying to learn the basics. I have a following problem concerning the convertion of array object into data frame. I have made following data sets tmp1 <- rnorm(100) tmp2 <- gl(10,2,length=100) tmp3 <- as.data.frame(cbind(tmp1,tmp2)) tmp3.sum <- tapply(tmp3$tmp1,tmp3$tmp2,sum) tmp3.sum <- as.data.frame(tapply(tmp1,tmp2,sum)) and I want the

Hi, LLVM community: I found basicaa seems not to tell must-not-alias for __restrict__ arguments in c/c++. It only compares two pointers and the underlying objects they point to. I wonder how clang does alias analysis for c/c++ keyword restrict. let assume we compile the following code: $cat myalias.cc float foo(float * __restrict__ v0, float * __restrict__ v1, float * __restrict__ v2, float *

Consider the following C code: typedef __attribute__(( ext_vector_type(2) )) float float2; typedef __attribute__(( ext_vector_type(2) )) __attribute__(( aligned(4) )) float float2_align2; void foo(void) { const float * p; size_t offset; float2 tmp = *((float2_align2 *)(p+offset)); } When compiled with clang ‹emit-llvm I get: define void @foo() { entry: %p = alloca float*, align 4

Hi all, I would like to know if LLVM Neon intrinsics are designed to support only 'Legal' types for NEON units. Using llc -march=arm -mcpu=cortex-a9 vmax4.ll -o vmax4.s on following ll code: ; ModuleID = 'vmax.ll' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-n32" target triple =