similar to: [LLVMdev] PROPOSAL: IR representation of detailed struct assignment information (new version)

On Thu, Sep 6, 2012 at 4:24 PM, Dan Gohman <gohman at apple.com> wrote: > Hello, > > Persuant to feedback, > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052927.html > > here is a new proposal for detailed struct assignment information. > > Here's the example showing the basic problem: > > struct bar { > char x; > float y; >

On Sep 6, 2012, at 4:24 PM, Dan Gohman <gohman at apple.com> wrote: > Hello, > > Persuant to feedback, > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052927.html > > here is a new proposal for detailed struct assignment information. Thanks Dan, > Here's the example showing the basic problem: > > struct bar { > char x; > float y; >

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

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 Chandler I also brainstormed a little with Dan on this and one idea we had was to add a new LLVM type for the hole/padding. This would be a type for which it is legal to load/store/move around as part of a larger move operation, but is otherwise unusable in LLVM. Dan named it x32 for a 32-bit type for example. I think this would fit well within what you are proposing as then it is easy to

On Mon, 10 Sep 2012 11:29:37 -0700 Chandler Carruth <chandlerc at google.com> wrote: > On Thu, Sep 6, 2012 at 4:24 PM, Dan Gohman <gohman at apple.com> wrote: > > > Hello, > > > > Persuant to feedback, > > > > http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052927.html > > > > here is a new proposal for detailed struct assignment

On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Wed, 22 Aug 2012 13:15:30 -0700 > Dan Gohman <gohman at apple.com> wrote: > >> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32 8, >> i1 false), !struct.assignment !4 […] > > I think that it would make more sense to name this !struct.tbaa -- it > seems logically

On Aug 27, 2012, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Mon, 27 Aug 2012 11:41:47 -0700 > Dan Gohman <gohman at apple.com> wrote: >> On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> On Wed, 22 Aug 2012 13:15:30 -0700 >>> Dan Gohman <gohman at apple.com> wrote: >>> >>>>

On Wed, 22 Aug 2012 13:15:30 -0700 Dan Gohman <gohman at apple.com> wrote: > 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 >

On 8/22/2012 3:15 PM, Dan Gohman wrote: > Here's an example showing the basic problem: > > struct bar { > char x; > float y; > double z; > }; > void copy_bar(struct bar *a, struct bar *b) { > *a = *b; > } > > We get this IR: > > call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32 8, i1 false) > > This works, but it

On Mon, 27 Aug 2012 11:41:47 -0700 Dan Gohman <gohman at apple.com> wrote: > On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > On Wed, 22 Aug 2012 13:15:30 -0700 > > Dan Gohman <gohman at apple.com> wrote: > > > >> call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* %1, i64 16, i32 > >> 8, i1 false),

On Aug 30, 2012, at 1:34 PM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote: > On 8/22/2012 3:15 PM, Dan Gohman wrote: >> Here's an example showing the basic problem: >> >> struct bar { >> char x; >> float y; >> double z; >> }; >> void copy_bar(struct bar *a, struct bar *b) { >> *a = *b; >> } >>

On Aug 27, 2012, at 10:15 PM, Chris Lattner <clattner at apple.com> wrote: > On Aug 27, 2012, at 12:58 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> On Mon, 27 Aug 2012 11:41:47 -0700 >> Dan Gohman <gohman at apple.com> wrote: >>> On Aug 24, 2012, at 10:50 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> On Wed, 22 Aug 2012

Hi Ma, how can I transform the llvm.memcpy into data move loop IR and eliminate > the bitcast instruction ? > I'm not sure why you are concerned about memcpy and bitcasts, but if you call MCpyInst->getSource() and MCpyInst->getDest() it will look through casts and give you the 'true' source/destination. If you want to get rid of memcpy altogether, you can take a look

Hi Craig Thank you very much ！ 2018-01-30 16:11 GMT+08:00 Craig Topper <craig.topper at gmail.com>: > The pointers must always be i8* the alignment is independent and is > controlled by the attributes on the arguments in the call to memcpy. > > ~Craig > > On Mon, Jan 29, 2018 at 11:45 PM, ma jun <jun.parser at gmail.com> wrote: > >> Hi >> >>

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 =

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

On Sep 10, 2012, at 11:29 AM, Chandler Carruth <chandlerc at google.com> wrote: > > Hey Dan, I've talked with you about this in person and on IRC, but I've not yet laid out my thoughts on a single place, so I'll put them here. > > TL;DR: I really like the idea of using metadata to tag each member of a struct with TBAA, and re-using the TBAA metadata nodes we already

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:

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