search for: metadataasvalue

...s an MDNode that was created as follows: Metadata* vals[2] = { ValueAsMetadata::get(&F), ValueAsMetadata::get(ConstantInt::get(context, 135)) }; MDNode* mdnode = MDNode::get(context, vals); Is it possible to extract the value of the constant int (135 in this case)? I tried using MetaDataAsValue as follows: cast<ConstantInt>(MetadataAsValue::get(context, mdnode->getOperand(1)))->getZExtValue() but I get NULL... (although when pronting the MetadataAsValue I do see "i32 135") maybe the MDNode should be built in a different manner...

Hi all, I'm dealing with LLVM's debug information metadata, and have run into an interesting edge case. Under normal circumstances, every `DILocalVariable` has a `User` in the form of the `llvm.dbg.*` intrinsic that produced it. Knowing this, I can go from `DILocalVariable` to `MetadataAsValue`, grab the users, and end up at the corresponding instruction + function. In some cases, however, LLVM will optimize the IR such that those intrinsics are no longer called, and their corresponding metadata is stashed in the `RetainedNodes` of each `DISubprogram` instead. For example: ; Funct...

...0x1f01653 SignalHandler(int) /usr/local/google/home/blaikie/dev/llvm/src/lib/Support/Unix/Signals.inc:198:60 #3 0x7f6893e22340 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x10340) #4 0x1ae3a9f bool llvm::DenseMapBase<llvm::SmallDenseMap<void*, std::pair<llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>, unsigned long>, 4u, llvm::DenseMapInfo<void*>, llvm::detail::DenseMapPair<void*, std::pair<llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>, unsigned long> > >, void*, std::pair<llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Me...

...heir use-list interface functions to make them no-ops. We > could also do this kind of specialization in the Use class (I think). Okay, let's actually think through how practical that is. The class hierarchy is: Value - Argument - BasicBlock - InlineAsm (huh, why is that not a constant?) - MetadataAsValue (+ children) - User -- Instruction (+ children) -- Constant --- ConstantData (undef, token none, literals) --- ConstantAggregate (non-literal aggregates) --- BlockAddress --- ConstantExpr --- GlobalValue (+ children) -- Operator (utility / facade, i.e. not real) -- DerivedUser (extension point used...

...ing: bool fpscan::ldAddMetadata (Instruction *Inst, StringRef c) { std::vector<Metadata *> dataTuples; // Add metadata in list dataTuples.push_back(MDString::get(Inst->getContext(), c)); MDNode* N = MDNode::get(Inst->getContext(), dataTuples); Value* meta = MetadataAsValue::get(Inst->getContext(), N); std::vector<Value*> args; args.push_back(meta); IRBuilder<> Builder(Inst->getNextNode()); Builder.CreateCall(dbglabelPtr, args, ""); } And before my pass finish, I print the IR, it shows I successfully add the intrinsic %5...

...working on, is as follows: // signal handling... #4 0x00005556e48d6120 llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&) (/home/sjessu/build-no-debug/bin/clang-10+0x2787120) #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*, llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2) #6 0x00005556e48dbc12 llvm::MDNode::MDNode(llvm::LLVMContext&, unsigned int, llvm::Metadata::StorageType, llvm::ArrayRef<llvm::Metadata*>, llvm::ArrayRef<llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/c...

Hi LLVM, If I have an llvm value "<16 x float> addrspace(1)* %in", and in the LLVM IR, there is a @llvm.dbg.value like: call void @llvm.dbg.value(metadata <16 x float> addrspace(1)* %in, i64 0, metadata !216, metadata !28), !dbg !217 How I can retrieve this @llvm.dbg.value when I have "%in"? Since Metadata is not a part of the uselist anymore, is there some way

...e. > > 4. Arguments to intrinsics. > > call void @llvm.dbg(metadata !{i32 %inst}, metadata !0) > > The first argument is subtle -- that's a function-local `MDNode` > with `%inst` as its only operand. > > In the new IR, the second operand will be a `MetadataAsValue` > instance that contains a reference to the `MDNode` numbered `!0`. > > New syntax > ---------- > > Types only make sense when an operand can be an `llvm::Value`. Let's > remove them where they don't make sense. > > I propose the following syntax for the a...

...ng... >> #4 0x00005556e48d6120 >> llvm::ReplaceableMetadataImpl::getOrCreate(llvm::Metadata&) >> (/home/sjessu/build-no-debug/bin/clang-10+0x2787120) >> #5 0x00005556e48db8c2 llvm::MetadataTracking::track(void*, >> llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, >> llvm::Metadata*>) (/home/sjessu/build-no-debug/bin/clang-10+0x278c8c2) >> #6 0x00005556e48dbc12 llvm::MDNode::MDNode(llvm::LLVMContext&, unsigned >> int, llvm::Metadata::StorageType, llvm::ArrayRef<llvm::Metadata*>, >> llvm::ArrayRef<llvm::Metadata*>...

...represent an extra > level of indirection. This is best demonstrated by the change to > IntrinsicInst.cpp in this patch [0] -- calling getVariableLocation on > any normal dbg.value will return the locations Value, but if it's an > implicit pointer then you'll get the meaningless MetadataAsValue > wrapper back instead. This isn't the variable location, might surprise > existing handlers of dbg.values, and just seems a little off. > > I can see why this route has been taken, but by putting a non-Value in > dbg.value's, it really changes what dbg.values represent, a v...

TL;DR: If you use metadata (especially if it's out-of-tree), check the numbered list of lost functionality below to see whether I'm trying to break your compiler permanently. In response to my recent commits (e.g., [1]) that changed API from `MDNode` to `Value`, Eric had a really interesting idea [2] -- split metadata entirely from the `Value` hierarchy, and drop general support for

> On Mar 20, 2020, at 12:34 PM, Nicholas Krause <xerofoify at gmail.com> wrote: > >> >> The problem isn’t constants or functions themselves, it is that they are instances of llvm::Value. Everything that walks a use/def list would have to run code that checks for this, and every call to inst->setOperand() would have to do locking or conditional locking. This would be

...; > 4. Arguments to intrinsics. > > call void @llvm.dbg(metadata !{i32 %inst}, metadata !0) > > The first argument is subtle -- that's a function-local `MDNode` > with `%inst` as its only operand. > > In the new IR, the second operand will be a `MetadataAsValue` > instance that contains a reference to the `MDNode` numbered `!0`. > > New syntax > ---------- > > Types only make sense when an operand can be an `llvm::Value`. Let's > remove them where they don't make sense. Hm, how does this interact with range metadata? Cu...

Hey folks, Would you all mind having a bit of a design discussion around the feature both at the DWARF level and the LLVM implementation? It seems like what's currently being proposed/reviewed (based on the DWARF feature as spec'd) is a pretty big change & I'm not sure I understand the motivation, exactly. The core point of my confusion: Why does describing the thing a pointer

...10e61c549 SignalHandler(int) + 345 4 libsystem_platform.dylib 0x00007fff9d1a852a _sigtramp + 26 5 libsystem_platform.dylib 0x0000000000000003 _sigtramp + 1659206387 6 clang 0x000000010df459d6 llvm::MetadataTracking::track(void*, llvm::Metadata&, llvm::PointerUnion<llvm::MetadataAsValue*, llvm::Metadata*>) + 262 7 clang 0x000000010e1bcf50 llvm::MetadataTracking::track(llvm::Metadata*&) + 64 8 clang 0x000000010e1bcefa llvm::TrackingMDRef::track() + 42 9 clang 0x000000010e1bcec6 llvm::TrackingMDRef::TrackingMDRef(llv...

...el of indirection. This is best demonstrated by the change to > >> IntrinsicInst.cpp in this patch [0] -- calling getVariableLocation on > >> any normal dbg.value will return the locations Value, but if it's an > >> implicit pointer then you'll get the meaningless MetadataAsValue > >> wrapper back instead. This isn't the variable location, might surprise > >> existing handlers of dbg.values, and just seems a little off. > >> > >> I can see why this route has been taken, but by putting a non-Value in > >> dbg.value's, it r...

...> +private: > + LLVMContext &Context; > > Out of curiosity, why do Metadata nodes all need to carry around a context? This seems like memory bloat that would be great to avoid if possible. There are two uses for the context: - RAUW. Metadata that can RAUW (`TempMDNode` and `MetadataAsValue`) need a context. Other metadata need access to a context when their operands get RAUW'ed (so they can re-unique themselves), but this could be passed in as an argument, so they don't need their own. - Reference counting. My sketch uses reference counting for all the...