search for: callbackvh

...is facility to library-level consumers. > > I hadn’t considered AssertVH, and I agree that losing it isn’t an option. > > Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds? I haven’t looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something. > > If you want methods to still be inlined in the non-assert case, you still have an ABI break in how you interpret the pointer... > I’m suggesting that AssertVH be redesigned: it could be a PointerUnion...

...t the exposure of this facility to library-level consumers. I hadn’t considered AssertVH, and I agree that losing it isn’t an option. Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds? I haven’t looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something. > We also have quite a few places in LLVM today that conserve memory usage in non-assert builds by removing unnecessary members of classes. We can say that this makes the ABI more fragile, but it is a valuable spac...

...ould avoid this issue in principle by just switching those AssertingVH to observing pointers, but then we would have dangling pointers. I'm pretty sure that any analysis that keeps pointers to IR is in fact ending up with dangling pointers like this. I've noticed that AssumptionCache using CallbackVH that allow it to update its data structures correctly in this case. Just using regular pointers will end up with dangling pointers in this scenario. This isn't a problem in practice since the analysis will hopefully be invalidated and stop holding the dangling pointers, but it just seems weird...

...l IR, I just think we should use a more direct and efficient in-memory encoding (and in-bitcode encoding if that isn't already suitably dense). Where would the encoding schema be specified? Note that there are simple things that can be done to make MDNodes more efficient in common cases. The CallbackVH is only necessary when pointing to Value*’s that are not MDNode/MDString, and Constants-other-than-GlobalValue. If we make MDNode detect when it has “all-immortal” operands (like most debug info nodes) then we could just store Value*’s directly. This would be a completely invisible implementation...

...ing those > > AssertingVH to observing pointers, but then we would have dangling > > pointers. I'm pretty sure that any analysis that keeps pointers to IR is > > in fact ending up with dangling pointers like this. > > > > I've noticed that AssumptionCache using CallbackVH that allow it to > > update its data structures correctly in this case. > > > > Just using regular pointers will end up with dangling pointers in this > > scenario. This isn't a problem in practice since the analysis will > > hopefully be invalidated and stop holdi...

...problem though. Caching is per Value there, so that is probably a genuine use case when we need to keep input analysis alive until the main pass is alive. A few more other thoughts on this topic. Can we perhaps have a special reference type for passes to reference other passes, something like a CallbackVH for passes and them somehow disallow holding onto passes via a pointer? There could also be a way to verify correctness. We could force-invalidate all passes that the pass does not declare to depend on, then hopefully bugs will unconditionally present themselves independent of the pipeline. Adam...

Hello, I'm currently developing a tool based on LLVM to understand how the LLVM IR changes after optimization passes are run. Today it's a tedious but automatic process at a function level in my language, where I first dump the IR before running any passes, and then do it for the 10 or so passes I care about one-at-a-time to understand which pass affected the change. There are two

...ular to redesigning the metadata format, >> but IMO it's worth doing as soon as it's possible. >> >> 4. Create `GenericDebugMDNode`, a transitional subclass of `MDUser` >> through an intermediate class `DebugMDNode` with an >> allocation-time-optional `CallbackVH` available for referencing >> non-metadata. Change `DIDescriptor` to wrap a `DebugMDNode` instead >> of an `MDNode`. >> >> This saves another ~960MB, for a running total of ~2GB. >> >> Proposed assembly syntax: >> >> !7 = metadata...

...to define the schema somewhere clearly. I'm just lobbying for the textual IR and the APIs to both operate directly on N fields, and just make the memory representation dense. > > Note that there are simple things that can be done to make MDNodes more > efficient in common cases. The CallbackVH is only necessary when pointing > to Value*’s that are not MDNode/MDString, and > Constants-other-than-GlobalValue. If we make MDNode detect when it has > “all-immortal” operands (like most debug info nodes) then we could just > store Value*’s directly. This would be a completely invi...

This thread kinda died. I'd like to revive it. The new PM stuff is making excellent progress, and this is actually one of the last things to clean up. On Mon, Aug 8, 2016 at 1:10 AM Sean Silva <chisophugis at gmail.com> wrote: > Thoughts? For the moment I have put in a workaround (r274457) that makes > jump-threading invalidate LVI. > > > Is everybody happy with this

...520MB. This is somewhat perpendicular to redesigning the metadata format, but IMO it's worth doing as soon as it's possible. 4. Create `GenericDebugMDNode`, a transitional subclass of `MDUser` through an intermediate class `DebugMDNode` with an allocation-time-optional `CallbackVH` available for referencing non-metadata. Change `DIDescriptor` to wrap a `DebugMDNode` instead of an `MDNode`. This saves another ~960MB, for a running total of ~2GB. Proposed assembly syntax: !7 = metadata !GenericDebugMDNode(tag: DW_TAG_compile_unit,...

Hello Visual Studio is complaining about the mix of struct and class. 2>C:\dev\llvm\include\llvm/ADT/ValueMap.h(202) : warning C4099: 'llvm::DenseMapInfo<llvm::ValueMapCallbackVH<KeyT,ValueT,Config,ValueInfoT>>' : type name first seen using 'struct' now seen using 'class' 2> C:\dev\llvm\include\llvm/ADT/ValueMap.h(251) : see reference to class template instantiation 'llvm::ValueMapCallbackVH<KeyT,ValueT,Config,ValueInfoT>'...

On Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote: >> Even when you have a !NDEBUG build, the platform assert() is pretty >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes >> just pops up a dialog. WebKit and other projects take the same approach >> and define their own assertion macros to deal with this portably. >>

...ata format, > >> but IMO it's worth doing as soon as it's possible. > >> > >> 4. Create `GenericDebugMDNode`, a transitional subclass of `MDUser` > >> through an intermediate class `DebugMDNode` with an > >> allocation-time-optional `CallbackVH` available for referencing > >> non-metadata. Change `DIDescriptor` to wrap a `DebugMDNode` instead > >> of an `MDNode`. > >> > >> This saves another ~960MB, for a running total of ~2GB. > > > > > > 2GB (out of 15.3GB i.e. ~13%) see...

On Tue, Sep 25, 2018 at 10:45 PM Chris Lattner <clattner at nondot.org> wrote: > So this is one of the reasons I find your patch to be problematic: it > isn’t fixing N^2 behavior, it is merely changing one N^2 situation for > another. AFAICT there are one of two possible cases in these sorts of > transformations: > > 1) These transformations are iteratively removing or

On Mon, Nov 11, 2013 at 11:29 PM, Chris Lattner <clattner at apple.com> wrote: > Hi Manman (and llvmdev), > > I filed these two bugs to track the ideas that I was cooking: > > http://llvm.org/bugs/show_bug.cgi?id=17891 > http://llvm.org/bugs/show_bug.cgi?id=17892 > > TL;DR: I'm saying we should go from: > > !14 = metadata !{i32 786445, metadata !1,

...mewhat perpendicular to redesigning the metadata format, > but IMO it's worth doing as soon as it's possible. > > 4. Create `GenericDebugMDNode`, a transitional subclass of `MDUser` > through an intermediate class `DebugMDNode` with an > allocation-time-optional `CallbackVH` available for referencing > non-metadata. Change `DIDescriptor` to wrap a `DebugMDNode` instead > of an `MDNode`. > > This saves another ~960MB, for a running total of ~2GB. > 2GB (out of 15.3GB i.e. ~13%) seems pretty pathetic savings when we have a single pie slice n...

...as the problem. — Mehdi > > In principle, one alternative is to trigger the invalidation of the cached analysis result right before we delete the thing it is holding the AssertingVH on. But then in what sense in the AssertingVH actually "asserting"? At that point it is just a CallbackVH that triggers invalidation. > > I don't think we want to force cache invalidation logic in every pass that deletes a Value. =[ > > So I think we should move away from AssertingVH in analysis results. If you need a more powerful debugging tool than ASan (or analogous) provides, we...

Hi Manman (and llvmdev), I filed these two bugs to track the ideas that I was cooking: http://llvm.org/bugs/show_bug.cgi?id=17891 http://llvm.org/bugs/show_bug.cgi?id=17892 TL;DR: I'm saying we should go from: !14 = metadata !{i32 786445, metadata !1, metadata !10, metadata !"y", i32 3, i64 32, i64 32, i64 32, i32 0, metadata !13} to: !14 = metadata

...that'd be nice too and maybe sufficient/instead/not worth the added complexity in debug info code of pulling out fields in the debug info handling code. > > >> >> Note that there are simple things that can be done to make MDNodes more >> efficient in common cases. The CallbackVH is only necessary when pointing >> to Value*’s that are not MDNode/MDString, and >> Constants-other-than-GlobalValue. If we make MDNode detect when it has >> “all-immortal” operands (like most debug info nodes) then we could just >> store Value*’s directly. This would be a...