similar to: An ambiguity in TBAA info format

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

Do you have a formal description of your approach with examples? I have a bit of trouble visualizing exactly what your approach does. On Mon, Aug 14, 2017 at 9:58 AM, Ivan A. Kosarev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello Steven, Hal and Daniel, > > Thanks a lot for your discussion; it really helps with summarizing current > TBAA issues and ways to resolve

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

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 Ivan, The code that we have is indeed different from what the 'standard llvm' expects. Let me explain: in our version we came into this situation in two steps: 1) I added support for 'special types' that map directly to types supported by hardware. These types are represented by a struct containing a single iXXX member, providing the necessary bits of the type, and at the

Hi, I have a question about the current definition of TBAA (See [1]). In the LLVM-IR code that we produce, we generate load/stores of struct types. (See [2] and [3] for a godbolt example showing the issue) For following c-alike code: struct S { int dummy; short e, f; } x,y; struct S* p = &x; int foobar() { x.f=42; *p=y; //**** struct copy return x.f; } We produce:

On Tue, Feb 14, 2017 at 5:51 AM, Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Mon, Feb 13, 2017 at 10:39 PM, Daniel Berlin <dberlin at dberlin.org> > wrote: > >> >> >> On Mon, Feb 13, 2017 at 10:07 AM, Hubert Tong < >> hubert.reinterpretcast at gmail.com> wrote: >> >>> On Mon, Feb 13, 2017 at 2:23 AM, Daniel

Daniel, Hal, I'm trying to figure out what we would need to do in terms of the current approach, accepting its limitations, to support unions, member arrays, aggregate accesses and type identifiers and what I get looks suspiciously simple. Can you please check it out and let me know if I'm missing something? For unions: TBAA, regardless of a specific approach, cannot guarantee

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 > >

On Mon, Feb 13, 2017 at 10:07 AM, Hubert Tong < hubert.reinterpretcast at gmail.com> wrote: > On Mon, Feb 13, 2017 at 2:23 AM, Daniel Berlin via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >>> I don't think this fully solves the problem -- you'll also need to fix >>> getMostGenericTBAA. That is, even if you implement the above scheme,

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, 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----

Hi Ivan, > As to my own patches pending publication, they are all for the new > TBAA format, which you said would be of no help in your case. > I actually thought they would help, but merely suggested an intermediate step while waiting for those further improvements you are working on. I would be happy to try your patches and evaluate if it helps my test case... thanks /Jonas

> > > > For two given access sequences we can determine if the accessed > objects are allowed to overlap by the rules of the input > language. Sadly, this is where this becomes "unlikely to want to use to replace TBAA", at least for me. It may still be a thing we want anyway. This scheme is really an encoding of C/C++ TBAA info so it can be read by LLVM and requires

On Sep 7, 2012, at 10:28 AM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 6, 2012, at 4:24 PM, Dan Gohman <gohman at apple.com> wrote: > >> Here's the example showing the basic problem: >> >> struct bar { >> char x; >> float y; >> double z; >> }; >> void copy_bar(struct bar *a, struct bar *b) { >> *a = *b;

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

Hello, Currently LLVM expects front-ends to lower struct assignments into either individual scalar loads and stores, or calls to @llvm.memcpy. For structs with lots of fields, it can take a lot of scalar loads and stores, so @llvm.memcpy is used instead. Unfortunately, using @llvm.memcpy does not permit full TBAA information to be preserved. Also, it unnecessarily copies any padding bytes between

What are you querying the alias analysis on in the above example - between the load and store? How are you creating your MemoryLocation for those too? On Fri, Nov 15, 2019 at 6:03 AM Venkataramanan Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Can someone please clarify me on this? > > > > On Wed, 13 Nov 2019 at 22:25, Venkataramanan Kumar < >

Hi I am upgrading my clang fork from 5.0 to 6.0 and I am hit by this error: Access type node must be a valid scalar type %4 = load %"struct.Foo::p.test1::"*, %"struct.Foo::p.test1::"** %_param.addr, align 8, !tbaa !16 !16 = !{!15, !15, i64 0} !15 = !{!"p.test1::", !13, i64 0, !13, i64 8} It looks like !16 is referencing !15, which is a struct. !13 is !13 =

On 02/11/17 05:54, Hal Finkel wrote: > > On 10/31/2017 05:02 AM, Ivan Kosarev wrote: >> To clarify further, what this paper proposes is to use !tbaa for all >> kinds of accesses, including aggregate ones, so we don't need to >> bother trying to convert them when an aggregate access becomes a >> series of scalar accesses or vice versa. As I said, in most cases