similar to: [LLVMdev] Alias analysis interface

Sorry the 1st example I gave it bit lame, it is changed to following: // a[] is local array, no addr taken. die right after the loop for (i = 0; i < N; i++) { a[i] = ... /* s1 */ sum += a[i-1]; } S1 could be easily deleted if alias analyizer say a[i] and a[i-1]. On 11/8/12 6:07 PM, Shuxin Yang wrote: > Hi, > > In today meeting, Dan gave a very

Hello, I'm afraid I don't understand your question. Could you restate your example and your question, and say what specifically you would like alias analysis to do? Dan On Fri, Nov 9, 2012 at 9:31 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Sorry the 1st example I gave it bit lame, it is changed to following: > > // a[] is local array, no addr taken. die right

>what specifically you would like alias analysis to do? Quite honestly, I don't know what interface is convenient for optimizer. I once implemented a flow-sensitive alias-analysis as a hobby project, which was able to disambiguate the subscripted variables like a[i] and a[i-1]. Unfortunately, the interface is pretty messy, that is why I solicit your insight on this issue. The problem

Hi, In the following instruction sequence, llvm.objectsize.i64(p) returns 6 (the entire *.ll is attached to the mail). Is this correct? Shouldn't the "object" refer to the entire block of memory being allocated? (char*) p = malloc(56) llvm.objectisize.i32(p+50); Thanks Shuxin This question is related to PR14988 (failure in bootstrap build with LTO). Part of the

Hi, There: Clang fails to compile 254.gap @ CPU2000int suite. The symptom is that executable fail to run with reference input. The root cause is that the compiler mistakenly optimizes expr "x * y / y" into x where the x*y is blindly flagged with nsw without any analysis. The preproceeded code is excerpted bellow: cat -n integer.i --------------------------------- 2361

Hi, There: I'd like to add bit, called "addr_not_taken", to GlobalVariable in order to indicate if a GlobalVariable doesn't has its address taken or not. 1.The motivation =============== The motivation can be explained by the following example. In this example, variable x does not have its address taken, therefore, it cannot be indirectly access. So, we can prove

This has come up before, and we just added -fwrapv to work around the problem: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110131/115969.html Are you compiling without -fwrapv? Cameron On May 6, 2013, at 4:55 PM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > Hi, There: > > Clang fails to compile 254.gap @ CPU2000int suite. The symptom is that executable

If the code is unreachable, such code is easy to be removed, and should be removed. If it is reachable, that is bit difficult to tell. Now that C std already give compiler such permit, perhaps we don't have to keep in sync with gcc. Otherwise, it is very difficult to delete dead non-countable loop. One might argue, do you see many dead non-countable loops? I don't know the answer, but

Thank you all for the input. Seems that I have to prove a non-countable loop is finite before I can delete it. BTW, I think this draft is not clear as to what is "constant expr". The source code may use symbolic value, but later on the symbolic value could be proved to be constant. However, compiler could mistakenly delete the loop before that point. Thank you all for the input

Hi, Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan() also expects the same definition, but I didn't review the code carefully. When you do a

On 11/14/2012 12:07 PM, Shuxin Yang wrote: > > If it is reachable, that is bit difficult to tell. Now that C std > already give compiler such permit, perhaps we don't have to keep > in sync with gcc. From the C standard (well, draft): ---- 6.8.5 Iteration statements [...] An iteration statement whose controlling expression is not a constant expression, that performs no

Hi, All: Is it legal to delete empty infinite loop like this : "while(1) {}"? It is interesting that both llvm and gcc keep the loop, however Open64 delete it. If it is safe to delete this loop, it would be lot easier to delete non-obvious dead loop like following as compiler doesn't need to prove if the loop in question is infinite or not. Currently llvm is not able to

On Feb 27, 2013, at 4:05 AM, Nuno Lopes <nunoplopes at sapo.pt> wrote: > Hi, > > Regarding the definition of object for @llvm.objectsize, it is identical to gcc's __builtin_object_size(). So it's not wrong; it's just the way it was defined to be. > > Regarding the BasicAA's usage of these functions, I'm unsure. It seems to me that isObjectSmallerThan()

A little background: The fmuladd intrinsic was introduced to support the FP_CONTRACT pragma in C. llvm.fmuladd.* is generated by clang when it sees an expression of the form 'a * b + c' within a single source statement. If you want to opportunistically form FMA target instructions my inclination would be to skip llvm.fmuladd.* and just form them from a*b+c expressions at isel time. I

Hi, Dear All: I'm going implement FMA formation. On some architectures, "FMA a, b, c" is more precise than "a * b + c". I'm wondering if FMA could be less precise. In the former case, can we enable FMA formation despite restrictive FP mode? Thanks Shuxin

I remember why I didn't implement this rule in Instcombine. It add one instruction. So, this xform should be driven by a redundancy eliminator if you care code size. On 8/8/13 10:13 AM, Shuxin Yang wrote: > I did few transformation in Instruction *InstCombiner::visitFDiv() in > an attempt to remove some divs. > I may miss this case. If you need to implement this rule, it is >

Maybe I were not clear in my previous mail, or maybe we are talking about different topics. My point was, if the pair of memory accesses are direct access, in most cases, the base/offset/size should be able to sufficient to figure out if they are alias or not. A tricky case would be subscripped variables, like a.b[i][j] vs a.c[m][n] where a.c and b.c are enclosed in a common union. If

>I think that the first step would be to expose Target Lowering Interface (TLI) to OPT's IR-level passes. By "lowering", we assume the bitcode is more abstract than the machine code. However, in some situations, it is just opposite. For instance, some architectures support vectorization of min/max/saturated-{add,sub)/conditional-assignment/etc/../etc. We need to detect such

Hi, 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? Thanks Shuxin 101 ; CHECK: test6 102 ; CHECK: insertelement <4 x float> zeroinitializer, float 1.000000e+00, i32 %idx1 103 ; CHECK:

Hi, Following is excerpted from http://llvm.org/releases/3.1/docs/LangRef.html#int_ctpop. How come the return type needs to be consistent with parameter type? i64/i128 seems to be overkill, and i8, i16 are inconvenient. ----------------------------------- declare i8 @llvm.ctpop.i8(i8 <src>) declare i16 @llvm.ctpop.i16(i16 <src>) declare i32 @llvm.ctpop.i32(i32