search for: omnipotence

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Wednesday, October 18, 2017 1:18 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: Michael Kruse <llvm at meinersbur.de>; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-18

Hello, Consider these two TBAA access tags: !1 = !{!5, !5, i64 0} !3 = !{!7, !7, i64 0} !5 = !{!"A", !9} !7 = !{!"B", !9} The tag !1 describes an access to an object of type "A" and !3 describes an access to object of type "B". Both the type descriptors, !5 and !7, refer to node !9 as their type group. A definition of that node could look like this:

On 31/10/17 01:48, Hal Finkel wrote: > On 10/30/2017 04:57 PM, Ivan Kosarev via llvm-dev wrote: >> Hello, >> >> Consider these two TBAA access tags: >> >> !1 = !{!5, !5, i64 0} >> !3 = !{!7, !7, i64 0} >> >> !5 = !{!"A", !9} >> !7 = !{!"B", !9} > > I'd find this email less confusing if you'd write out all of

Hi Roel, the code you list below is precisely what I expect to get (of course the stores must happen but the constant folding should happen as well). It all looks very strange. LLVM is behaving as if the __restrict__ keyword was not used at all. Even more strange is the fact that for this function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z) { *x = 1.0;

Hi, It was a while now since I first asked about TBAA, and I am now getting back to this, trying to understand TBAA as it seems that the issue I described earlier originally in this thread is still one of many "TODO"s in CGExpr.cpp (http://lists.llvm.org/pipermail/llvm-dev/2018-September/126290.html). I would like to help on this to the best of my abilities, but I'm not quite

Hi LLVMers, I would like to ask a question regarding aliasing. Suppose I have the following program: double f(double** p ) { double a,b,c; double * x = &a; double * y = &b; double * z = &c; *x = 1; *y = *x + 2; *z = *x + 3; return *x+*y+*z; } LLVM can tell that the three pointers do not alias each other so can perform the constant folding at compile time.

Hi Brent, Looking at your code I can see at least one reason why some of the store operations remain in the output since you are (through x, y, and z) writing in memory which exists outside of your function (p). Constant propagation also seems to work in the first few lines, *y = *x +1 (%3) is stored directly. The strange thing to me is that the same doesn't happen for *z = *x + 2. Here

Hi Brent, I think this is a problem in the easy-cse transform. In this transform load operations can be replaced by their subexpression, in this case the propagated constant, based on the value of the 'CurrentGeneration' of memory writes. This implies that any store operation invalidates the knowledge about previously stored subexpressions. In general, this is a safe assumption but

Can you explain please why it works for this version of the function: double f(double *__restrict__ x, double *__restrict__ y, double *__restrict__ z); What is different here? There are stores here as well. Brent On Wed, Jan 25, 2012 at 12:34 AM, Roel Jordans <r.jordans at tue.nl> wrote: > Hi Brent, > > I think this is a problem in the easy-cse transform. In this transform

I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. It works on arguments because they can be given the 'noalias' attribute, and then the alias analyzer must understand what that means. Pete On Jan 24, 2012, at 7:47 AM, Roel Jordans wrote: > I have no clue, I didn't have time to look into that example yet.

I have no clue, I didn't have time to look into that example yet. How does the IR (before optimization) differ from the other version? Roel On 01/24/2012 04:45 PM, Brent Walker wrote: > Can you explain please why it works for this version of the function: > > double f(double *__restrict__ x, double *__restrict__ y, double > *__restrict__ z); > > What is different here?

Hi, I have the following LLVM IR. ----Snip--- %1 = getelementptr inbounds %struct._X, %struct._X* %0, i64 0, i32 3 %2 = load %struct._X*, %struct._X** %1, align 8, !tbaa !10 .... ..... ....... %3 = bitcast %struct._Y** %1 to i8** store i8* null, i8** %3, align 8, !tbaa !9 !9 = !{!7, !7, i64 0} !7 = !{!"omnipotent char", !8, i64 0} !8 = !{!"Simple C/C++ TBAA"} ----Snip----

To be honest, the 'Dynamic Bind' method doesn't seem that secure to me, anybody could 'pretend' to be someone else. Rowland True! I agree with you Rowland that is a weakness. Unfortunately that is a universal weakness shared by all password-based authentication methods. I guess you would have to go with SSH-style encryption keys and certificates to circumvent that problem

Hello all, I'm new to the llvm community. I'm learning how things work. I noticed that there has been some interest in improving how unions are handled. Bug 21725 is one example. I figured it might be a interesting place to start. I discussed this with a couple people, and below is a suggestion on how to represent unions. I would like some comments on how this fits in with how

Peter Cooper wrote: > I think the problem here is that the IR doesn't have any way to attach restrict information to loads/stores/pointers. I think we do now, actually. Now that the loads and stores have TBAA metadata, I think the restrict attribute can go there. It needs to be attached to every use of a restrict pointer, but that's similar to how TBAA already works. > It works

Hi Daniel, I see your point about LLVM and C/C++ type agnostic. I think TBAA was invented to partially cover this gap and give optimization opportunities when LLVM types are not sufficient but C/C++ types have required information. What do you think about following example: struct S { int a[10]; int b; }; int foo(struct S *ps, int i) { ps->a[i] = 1; ps->b = 2; return

Hi LLVM, I am using 3.0, and I have a question about the __thread in c and thread_local in LLVM IR: O1-O4 and the final linked code behave differently. //////////////////////////////////// The following C code is from the LLVM testcase (SingleSource/UnitTests/Threads/2010-12-08-tls.c) #include <stdio.h> __thread int a = 4; int foo (void) { return a; } int main (void) {

Hi Ivan, On 2019-01-17 18:09, Ivan Kosarev wrote: > Hello, Jonas, > > > It seems that when the struct member is an array, the base type > > becomes the element type. This is simply unhandled still in > > CodeGenTBAA ("TODO"). My question then is if it would be > > possible to instead create the DAG nodes !"A" and !"B" (as in > >

Hi all, I have a question regarding dynamic indexing into a vector with GEP. I see that in the ScalarReplAggregates pass in the LLVM 3.2 release the call SROA::isSafeGEP() will now allow alloca scalarization in the case where a GEP index into a vector isn’t a constant. My question is: what is the expected behavior when the index is out of bounds of the vector? Is it undefined? I have an

> -----Original Message----- > From: meinersbur at googlemail.com [mailto:meinersbur at googlemail.com] On > Behalf Of Michael Kruse > Sent: Tuesday, October 17, 2017 3:26 PM > To: Song, Ruiling <ruiling.song at intel.com> > Cc: llvm at meinersbur.de; llvm-dev at lists.llvm.org > Subject: Re: Possible bug of Alias Analysis? > > 2017-10-17 8:45 GMT+02:00 Song,