similar to: [LLVMdev] PROPOSAL: IR representation of detailed struct assignment information

On Aug 31, 2012, at 3:13 PM, Chris Lattner <clattner at apple.com> wrote: > 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;

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

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

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 8/28/2012 12:22 AM, Chris Lattner wrote: > Instead of implementing this, it would be a lot easier for clang to walk a type and produce a mask describing all the holes in a type, using a simple recursive algorithm (where union intersects the member "hole sets", finding that byte 3/4 of the union is a hole). > > Given this, it makes a lot more sense to explicitly model this

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;

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 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 Sep 10, 2012, at 2:54 PM, Hal Finkel <hfinkel at anl.gov> wrote: > On Mon, 10 Sep 2012 11:29:37 -0700 > Chandler Carruth <chandlerc at google.com> wrote: > >> >> Essentially, LLVM is trying to simplify ABI layout by providing a >> datalayout summary description of target alignments, and building >> structs with that algorithm. But unless this

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

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, Sep 10, 2012 at 2:11 PM, Dan Gohman <gohman at apple.com> wrote: > 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

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

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

On Aug 27, 2012, at 11:37 AM, gohman at apple.com wrote: > On Aug 24, 2012, at 5:56 PM, Alex Rosenberg <alexr at leftfield.org> wrote: > > > If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct

If we can also describe the alignment padding inserted at the end of a struct when it is placed in an array, then we can improve the current LoopIdiom pass to build more memcpys. I would think that would be attached to the struct definition. Alex On Aug 22, 2012, at 1:15 PM, Dan Gohman wrote: > Hello, > > Currently LLVM expects front-ends to lower struct assignments into either >