similar to: [LLVMdev] Merging custom metadata

Nick, First, thanks for responding. Secondly, I just want to create an exact copy of an already exisitng Value, this should be pretty simple to do but I'm unclear on how to do this? For example, PHINode::getIncomingValue (unsigned) returns a "Value" and I want to make a copy of that Value. Is there some other way to do this other than copyValue() that I'm missing? On Sat,

Ryan Taylor wrote: > Since there are no constructors for Value, how do you properly insert a > new Value? Value is a pure base. If you want to construct a new Value, then you want to construct a global variable or instruction or argument or something in particular. > If I create a pointer Value *newValue and then call > AA.copyValue(oldValue, newValue), this does not work, since

On Fri, Jan 18, 2013 at 10:00 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > f90_array_type = type { i32 size, double* data }; I am not certain how fortran implements multi-dimensional arrays, but in my case I'm doing something like type { i32 nd, i32* dims, double* data }; Perhaps we could add !tbaa.pointer? !1 = metadata !{ metadata !"int",

Since there are no constructors for Value, how do you properly insert a new Value? If I create a pointer Value *newValue and then call AA.copyValue(oldValue, newValue), this does not work, since newValue is not allocated. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120203/44086cf5/attachment.html>

On Jan 17, 2013, at 9:27 PM, Dimitri Tcaciuc <dtcaciuc at gmail.com> wrote: > Hey everyone, > > I'm looking at the following two C functions: > > http://pastebin.com/mYWCj6d8 > > Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved out of the second loop and are computed every time j

Hey everyone, I'm looking at the following two C functions: http://pastebin.com/mYWCj6d8 Second one is about 50% slower than the first one because in the second case d->data[i * 3 + {X, Y, Z}] loads are not moved out of the second loop and are computed every time j increments, even though they don't depend on it. If I move those out manually, the performance of the two is equal.

I'm wondering if it makes sense to instead supply a bc math library. I would think it would be easier to maintain and debug, and should still give you all of the benefits. You could just link with it early in the optimization pipeline to ensure inlining. This may also make it easier to maintain SIMD functions for multiple backends. On Sun, Jan 27, 2013 at 8:49 AM, Hal Finkel <hfinkel

On Jan 30, 2012, at 11:34 AM, Dan Gohman wrote: > Even if we single out TBAA, recall that TBAA was one of the main > motivations for the design of MDNodes -- it's in the second sentance, > and most of the last paragraph, of > http://blog.llvm.org/2010/04/extensible-metadata-in-llvm-ir.html ... and in last paragraph the author says ... "This use of metadata is also safe,

On 1/18/2013 11:34 AM, Hal Finkel wrote: > > I agree. FWIW, I'm currently working on making the LLVM-based Fortran compiler non-hypothetical, and so for several reasons, I'd like to have a solution to this. If we can't think of anything better, we could always fall back to the N^2 metadata solution (explicit mark as no-alias all pairs that don't alias), but I'd rather we

----- Original Message ----- > From: "Dimitri Tcaciuc" <dtcaciuc at gmail.com> > To: llvmdev at cs.uiuc.edu > Sent: Sunday, January 27, 2013 3:42:42 AM > Subject: [LLVMdev] SIMD trigonometry/logarithms? > > > > Hi everyone, > > > I was looking at loop vectorizer code and wondered if there was any > current or planned effort to introduce SIMD

Hi, I work on DDC, the compiler of a research Haskell dialect, Disciple (disciple.ouroborus.net (http://disciple.ouroborus.net)). We are looking to make use of LLVM's type-based alias analysis metadata to encode non-aliasing information between variables. We have found that the tbaa structure is somewhat limited in its expressivity. In particular we couldn't encode intransitive

On Jan 30, 2012, at 10:08 AM, Devang Patel wrote: > > On Jan 27, 2012, at 5:00 PM, Dan Gohman wrote: > >> Not all of these are miscompiles, > > None I'd say, may be TBAA. Then you missed value ranges and fpaccuracy. Anyway, here are some examples of optimizations which aren't implemented yet, but which have been seriously considered: metadata to mark C++ copy

On Jan 27, 2012, at 3:40 PM, Devang Patel <dpatel at apple.com> wrote: > [ removing cfe-dev from the cc list ] > > On Jan 27, 2012, at 1:31 PM, Dan Gohman wrote: > >> On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: >> >>> >>> On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: >>> >>>> On Jan 26, 2012, at 12:54 PM, Devang

I was trying to add some stronger assertions in the verifier around !tbaa metadata when I ran into an ambiguity: I think the encoding of the metadata nodes are such that a given node can be interpreted as either a struct type node or a scalar tbaa node. I'd like a sanity check before I try to fix or work around this. Consider some IR that I got from running clang over a small C++ program:

Hi, I am looking at the Type Based Alias Analysis and I am trying to understand why, from what I see, pointsToConstantMemory() never returns true. It seems that this information should come from the TBAA metadata, in which the Access Tag has an optional 4th field to specify this information. "Access tags are represented as MDNode s with either 3 or 4 operands. The first operand is an

Hi I do not really understand why frontend generated TBAA metadata is needed for the TBAA pass to work. It seems to me that we can always go up the IR chain and find the base type from which the pointer is derived from. Take the following example. I know %0 = load i32, i32* %a, align 4, !tbaa !1 and store i32 %i.02, i32* %b, align 4, !tbaa !6 do not alias as their metadata !1 = !{!2, !3, i64

On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: > On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >> >> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >> >>> or what optimizers must do to preserve it. >> >> The number one reason behind metadata is to have a mechanism to track values while being completely transparent to optimizer. If you want a

Hi Dan, I was thinking about having dragonegg produce tbaa.struct metadata and I realized that there is a problem with variable sized structs. What I have in mind is for example a struct with a few ordinary fields and a variable length array at the end. In Ada these can be copied; dragonegg turns such copies into calls to llvm.memcpy with a non-constant size parameter. It would be nice to use

[ removing cfe-dev from the cc list ] On Jan 27, 2012, at 1:31 PM, Dan Gohman wrote: > On Jan 27, 2012, at 11:20 AM, Devang Patel wrote: > >> >> On Jan 26, 2012, at 2:10 PM, Dan Gohman wrote: >> >>> On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: >>>> >>>> On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: >>>>

On Thu, 2012-01-26 at 14:10 -0800, Dan Gohman wrote: > On Jan 26, 2012, at 12:54 PM, Devang Patel wrote: > > > > On Jan 26, 2012, at 11:15 AM, Dan Gohman wrote: > > > >> or what optimizers must do to preserve it. > > > > The number one reason behind metadata is to have a mechanism to track values while being completely transparent to optimizer. If you