similar to: [LLVMdev] Request for comments: TBAA on call

On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: > Hi all, > > TBAA on loads and stores is super useful for conveying high-level type > knowledge to LLVM transformations. But often translating a high-level > language into LLVM IR will result in runtime calls that are known at the > high level to only affect (either by reading or by writing) some

On Oct 7, 2013, at 3:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: > Hi all, > > TBAA on loads and stores is super useful for conveying high-level type knowledge to LLVM transformations. But often translating a high-level language into LLVM IR will result in runtime calls

On Mon, Oct 7, 2013 at 4:22 PM, Filip Pizlo <fpizlo at apple.com> wrote: > > > On Oct 7, 2013, at 3:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > > On Wed, Sep 25, 2013 at 5:50 PM, Filip Pizlo <fpizlo at apple.com> wrote: >> >> Hi all, >> >> TBAA on loads and stores is super useful for conveying high-level type

I think we’re talking cross-purposes at this point. Let me try to step back and concisely restate what I’m trying to do: - I am writing a frontend for a high-level language and I emit LLVM IR. - I control the TBAA tree. I don’t use it to express the high-level language’s types, since that would make absolutely no sense. JavaScript doesn’t have types. But by the time my compiler is generating

TBAA MDNodes should describe the type hierarchy (with struct-path aware TBAA, it is a type DAG). It sounds okay to me to add !tbaa.call to function calls to describe which fields of the type system the call is touching. One example can be !tbaa.call {read a list of tag nodes, write a list of tag nodes}. Thanks, Manman On Mon, Oct 7, 2013 at 11:49 PM, Daniel Berlin <dberlin at dberlin.org>

On Mon, Oct 7, 2013 at 7:34 PM, Filip Pizlo <fpizlo at apple.com> wrote: > I think we’re talking cross-purposes at this point. Let me try to step > back and concisely restate what I’m trying to do: > > - I am writing a frontend for a high-level language and I emit LLVM IR. > - I control the TBAA tree. I don’t use it to express the high-level > language’s types, since

On Tue, Oct 8, 2013 at 12:45 PM, Manman Ren <manman.ren at gmail.com> wrote: > > TBAA MDNodes should describe the type hierarchy (with struct-path aware > TBAA, it is a type DAG). > It sounds okay to me to add !tbaa.call to function calls to describe which > fields of the type system the call is touching. > I agree wholeheartedly :). However, that's not what is being

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 5:00 PM, Dan Gohman wrote: > Not all of these are miscompiles, None I'd say, may be TBAA. > but the point is that valid but > naive optimizations can cause them to be actively misleading ... but not cause mis-compilation. Note, optimization passes are free to update info conveyed through MDNodes, if they want to. The "optional to update" while still

On Jan 27, 2012, at 3:40 PM, Devang Patel 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 Patel wrote:

śr., 5 gru 2018 o 00:22 John McCall via cfe-dev <cfe-dev at lists.llvm.org> napisał(a): > On 4 Dec 2018, at 17:50, Philip Reames wrote: > > Skimming along, apologies if I'm repeating something which already got > said. > > If I understand this correctly, the basic problem we're trying to solve is > to use a local hint (the invariant.group) to make a global

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: >>> >>>> or what optimizers must do to preserve it. >>> >>> The number one reason behind metadata is to have a

On 12/4/18 3:21 PM, John McCall wrote: > > On 4 Dec 2018, at 17:50, Philip Reames wrote: > > Skimming along, apologies if I'm repeating something which already > got said. > > If I understand this correctly, the basic problem we're trying to > solve is to use a local hint (the invariant.group) to make a > global assumption about other code

[ 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 Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Thu, Oct 10, 2013 at 10:34 AM, Chris Lattner <clattner at apple.com> wrote: > On Oct 7, 2013, at 11:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >> Hence it’s more meaningful to reason about TBAA in terms of its semantics rather than hypothesizing about

BTW, in any case, can we at least agree that updating the langref and comments all over the codebase that specify the tbaa tree is tied strictly to type hierarchy rules should be in scope to be updated to talk about an abstract heap hiearchy (with traditional type based as an example) instead? On Fri, Oct 11, 2013 at 12:17 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > >

On Thu, Oct 10, 2013 at 9:56 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > > On Thu, Oct 10, 2013 at 10:34 AM, Chris Lattner <clattner at apple.com>wrote: > >> On Oct 7, 2013, at 11:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: >> >>

On Thu, Oct 10, 2013 at 10:34 AM, Chris Lattner <clattner at apple.com> wrote: > On Oct 7, 2013, at 11:49 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > >> Hence it’s more meaningful to reason about TBAA in terms of its semantics >> rather than hypothesizing about how and why someone would produce it. >> > > That would be great, but it's not

On Thu, Oct 10, 2013 at 9:34 PM, Chris Lattner <clattner at apple.com> wrote: > On Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > The datastructures and algorithms we have are powerful enough to express >> these sorts of things, and so long as a frontend abided by the rules, there >> shouldn't be a problem. >> > > >

Daniel, Indulge me one more mail and I will go away … (or I'll try to :) On Feb 15, 2013, at 6:38 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > yes, it does, but this is somewhat irrelevant to C. > > The pointers will not be of type struct.a[x] *, they will be of type > int (*[100])) or int * or whatever But using the type system, aliasing, and language rules you