search for: valueasmetadata

Hello, I'm trying to extract the value out of my MDNode, but for some reason I can't. For example, if one part of the code gets 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,...

.... Since very little metadata needs to be RAUW'ed, we don't want to pay memory at every use-site. Instead, we pay the cost inside the (hopefully) few instances that support RAUW. The core assumption is that there are relatively few replaceable metadata instances. The only subclasses are `ValueAsMetadata` and `TempMDNode`. How many of these are live? - There will be at most one `ValueAsMetadata` instance for each metadata operand that points at a `Value`. My data from a couple of months ago showed that there are very few of these. - `TempMDNodes` are used as forward references. You...

...t;def> = VLOAD_D_WO_IMM; MSA128D:%vreg12 dbg:IfVectorize.c:39:5 INLINEASM <es: (Param1 - Param2); // MSA_I10> [sideeffect] [attdialect], <llc: /llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::ValueAsMetadata; Y = const llvm::Metadata; typename llvm::cast_retty<X, Y*>::ret_type = const llvm::ValueAsMetadata*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed. #0 0x00007f50baa5c700 llvm::sys::PrintStackTrace(llvm::raw_ostream...

Hello everyone, If I understand correctly after the Metadata/Value split the Metadata support of RAUW is limited by ValueAsMetadata and MDNodeFwdDecl (i.e. until cycled in MDNode are not resovled). And my question is. Is where any way to replace an MDNode which is referenced by other MDNodes w\o iterating over all MDNodes in LLMVContext to find and replace those references? Unfortunately I couldn't find such example in LLVM...

...> seem to be that much different from any other implicit values (such as > constants) to me. Why do you think that it needs to be represented > differently inside of LLVM IR? > > I think it's almost entirely that the first argument to dbg.value will > change from "Always ValueAsMetadata" to "Maybe metadata, maybe > Value". What changes do you have in mind there? Are you referring to the possibility of implicit values to refer to other variables? I'm sort of interested in maybe not doing that - and only implementing a more general form (what's been talk...

...data::getMetadataID() const > (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x100284453) > #1 0x10c4a8468 in > llvm::ReplaceableMetadataImpl::replaceAllUsesWith(llvm::Metadata*) > (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101587468) > #2 0x10c4a9317 in llvm::ValueAsMetadata::handleDeletion(llvm::Value*) > (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x101588317) > #3 0x10c4f5be0 in llvm::Value::~Value() > (/Users/dexonsmith/data/llvm.asan/staging/bin/clang+0x1015d4be0) > #4 0x10c35f22d in llvm::ConstantInt::~ConstantInt() > (/Users/dexons...

> On Jan 2, 2020, at 6:37 AM, Jeremy Morse <jeremy.morse.llvm at gmail.com> wrote: > > Hi all, > > On the topic of intrinsics, right now we have two (dbg.value / > dbg.addr) that respectively describe: > * The "direct value" (quoting langref) of a variable, and > * The address of where the current variable value is stored. > Both of which map onto dwarf

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

...n the IR. > > 1. Operands of `MDNode`. > > !0 = metadata !{metadata !"string", metadata !1, i32* @global) > > Notice that the `@global` argument is not metadata: it's an > `llvm::Constant`. In the new IR, these will be wrapped in a > `ValueAsMetadata` instance. > > 2. Operands of `NamedMDNode` (yes, they're different). > > !named = metadata !{metadata !0, metadata !1} > > These operands are always `MDNode`. > > 3. Attachments to instructions. > > %inst = load i32* @global, !dbg !0 &gt...

...be modified by a debugger. This can be fixed with some pattern matching in the DwarfExpression class to cover this specific (albeit common) case. The current approach for the IR is not to add a new instruction, but to add a new metadata node that contains a list of IR value references (wrapped as ValueAsMetadata) and use it as the first argument to dbg.value. There is no syntactic incompatibility between this and the current dbg.value, and therefore it is possible to support both simultaneously, but I believe it would be unnecessarily complicated to maintain two separate forms of dbg.value. There is no imm...

...t;Key Instructions" from Caroline Tice's thesis, but I can't claim this idea is totally faithful to it. For assignments to memory locations that are not local variables (*p = v, this->m = v), replace the local variable metadata argument with the value of the store destination, using ValueAsMetadata. Standard cleanup passes (instcombine, inliner?) should transform dbg.values with memory destinations that point into an alloca with the corresponding local variable for the alloca. This allows passes that delete stores other than mem2reg (DSE, Instcombine, GVN, anything using MemorySSA) to not wor...

...that no-longer-referenced metadata gets cleaned up. - Upgrade `DebugLoc` from 8 bits of column info to 16. - ... and get back to the debug info IR changes that get me into this mess :). (I actually tried really hard to get half of this working without the other half. I created the `ValueAsMetadata` bridge and restricted `MDNode` to only have subclasses of `Metadata` as operands, but left `Metadata` inheriting from `Value`. This only took a few days to get compiling, but left tons of errors to be found at runtime due to failing `cast<>` failures. Although there are small things that I...

Hi Duncan, I came across something like the following recently which I guess might be related to your recent work. Any ideas? $ clang++-tot -cc1 crash_on_invalid.cpp -g -emit-obj -fexceptions -fcxx-exceptions crash_on_invalid.cpp:13:1: error: C++ requires a type specifier for all declarations x; ^ 1 error generated. *** Error in `clang++-tot': corrupted double-linked list: 0x000000000754f340

...rence in the IR. > > 1. Operands of `MDNode`. > > !0 = metadata !{metadata !"string", metadata !1, i32* @global) > > Notice that the `@global` argument is not metadata: it's an > `llvm::Constant`. In the new IR, these will be wrapped in a > `ValueAsMetadata` instance. > > 2. Operands of `NamedMDNode` (yes, they're different). > > !named = metadata !{metadata !0, metadata !1} > > These operands are always `MDNode`. > > 3. Attachments to instructions. > > %inst = load i32* @global, !dbg !0 > &g...

...ifferent from any other implicit values (such as > constants) to me. Why do you think that it needs to be represented > differently inside of LLVM IR? > >> > >> I think it's almost entirely that the first argument to dbg.value will > >> change from "Always ValueAsMetadata" to "Maybe metadata, maybe > >> Value". > > > > What changes do you have in mind there? Are you referring to the > possibility of implicit values to refer to other variables? > > > > I'm sort of interested in maybe not doing that - and only imp...

On Fri, Oct 9, 2020 at 9:38 AM Cazalet-Hyams, Orlando < orlando.hyams at sony.com> wrote: > Hi Reid, > > > > Thanks for sharing this. I plan to work on improving debug-info for > variables > > living in memory as my next "project" so I am very interested to hear with > what > > others have to say about "Idea 1". > > > > There

...ied by a debugger. This can be fixed with some pattern matching in the DwarfExpression class to cover this specific (albeit common) case. > > The current approach for the IR is not to add a new instruction, but to add a new metadata node that contains a list of IR value references (wrapped as ValueAsMetadata) and use it as the first argument to dbg.value. There is no syntactic incompatibility between this and the current dbg.value, and therefore it is possible to support both simultaneously, but I believe it would be unnecessarily complicated to maintain two separate forms of dbg.value. There is no imm...

Hi John, I have looked into the EmitAutoVarAlloca() in CGDecl.cpp. However, I could not figure out how to employ my custom attribute for code generation. For example, my custom attribute is visible in CGDecl.cpp but how can I generate based on my custom attribute if (D.hasAttr<myCustomAttri>()) { //What to do here? } What I wan in IR is something like below. Without Custom Attribute: