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

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

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; double z; }; void copy_bar(struct bar *a, struct bar *b) { *a = *b; } The solution I now propose here is to have front-ends describe the copy using

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 >

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

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

<moving this to llvmdev now that the lists are back up!> On Aug 23, 2012, at 4:37 PM, Dan Gohman <gohman at apple.com> wrote: > On Aug 23, 2012, at 4:05 PM, Chris Lattner <clattner at apple.com> wrote: >> On Aug 23, 2012, at 3:59 PM, Dan Gohman <gohman at apple.com> wrote: >>> On Aug 23, 2012, at 3:31 PM, Chris Lattner <clattner at apple.com> wrote:

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