search for: hasvaluehandler

...erent LLVMContext for the destination module, but it >> didn’t work out since Linker was not designed to work with different >> LLVMContexts for source vs destination. >> 2> removeUnusedMDNodes checks if a MDNode is used in a different way >> (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes >> that form cycles. >> > > 3) Make the MDNode be owned by the module that uses it? > MDNode is shared among modules so multiple modules can use it, if we specify an owner for a MDNode, that will prevent sharing. Manman -------------- next p...

...ther options are: 1> Using a different LLVMContext for the destination module, but it didn’t work out since Linker was not designed to work with different LLVMContexts for source vs destination. 2> removeUnusedMDNodes checks if a MDNode is used in a different way (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes that form cycles. Comments and suggestions are welcome. Thanks, Manman -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/d1714eca/attachment.html>

...t for the destination module, but it >>> didn’t work out since Linker was not designed to work with different >>> LLVMContexts for source vs destination. >>> 2> removeUnusedMDNodes checks if a MDNode is used in a different way >>> (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes >>> that form cycles. >>> >> >> 3) Make the MDNode be owned by the module that uses it? >> > > MDNode is shared among modules so multiple modules can use it, if we > specify an owner for a MDNode, that will prevent shar...

When trying to display and do anything with a variable of type IntrinsicInst, gdb thinks that it's an incomplete type and kind find any member functions or even display the class. (gdb) list 1337 1332 1333 // Finish off the call including any return values. 1334 return finishCall(CLI, RetVT, NumBytes); 1335 } 1336 1337 bool MipsFastISel::fastLowerIntrinsicCall(const

On Tue, Sep 15, 2009 at 11:37 PM, Devang Patel <devang.patel at gmail.com> wrote: > On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote: >> Devang's work on debug info prompted this, thoughts welcome: >> http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt > > Here is partial initial implementation. > Thoughts ? setHasMetadata

...gt; Using a different LLVMContext for the destination module, but it didn’t > work out since Linker was not designed to work with different LLVMContexts > for source vs destination. > 2> removeUnusedMDNodes checks if a MDNode is used in a different way (i.e > use_empty() && !hasValueHandler()), but it does not remove MDNodes that > form cycles. > 3) Make the MDNode be owned by the module that uses it? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131112/22442859/attachment.html>

...ns are: > 1> Using a different LLVMContext for the destination module, but it didn’t work out since Linker was not designed to work with different LLVMContexts for source vs destination. > 2> removeUnusedMDNodes checks if a MDNode is used in a different way (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes that form cycles. > > 3) Make the MDNode be owned by the module that uses it? > > MDNode is shared among modules so multiple modules can use it, if we specify an owner for a MDNode, that will prevent sharing. > > From your stats (40% stuck in...

Ok. I'm basically just following the model of the other fast-isel ports. On 01/30/2015 09:12 PM, David Blaikie wrote: > (I'm assuming you're building LLVM with clang, in this case?) > > Looks like IntrinsicInst is one of those "lies" in LLVM that works via > type punning that's undefined behavior in C++, so it's code that > should be fixed anyway.

On Sun, Mar 17, 2019 at 1:47 PM Craig Topper <craig.topper at gmail.com> wrote: > Can we move HasValueHandle out of the byte used for SubClassOptionalData and move it to the flags at the bottom of value by shrinking NumUserOperands to 27? I like this approach because it is less work for me. :) But I agree with Sanjay below that this only kicks the can slightly further down the road

(I'm assuming you're building LLVM with clang, in this case?) Looks like IntrinsicInst is one of those "lies" in LLVM that works via type punning that's undefined behavior in C++, so it's code that should be fixed anyway. In any case, the reason this produces the debugging experience you're seeing is that LLVM (& GCC, for that matter) assumes that if your class

Hi, I need to add a flush-denormals-to-zero (FTZ) flag to FastMathFlags, but we've already used up the 7 bits available in Value::SubclassOptionalData (the "backing storage" for FPMathOperator::getFastMathFlags()). These are the possibilities I can think of: 1. Increase the size of FPMathOperator. This gives us some additional bits for FTZ and other fastmath flags we'd want

On Fri, Jan 30, 2015 at 10:37 PM, reed kotler <rkotler at mips.com> wrote: > Ok. > > I'm basically just following the model of the other fast-isel ports. > Yeah, not your fault - just an architectural quirk. It's possible we could workaround the debug info side of this by declaring the virtual dtor (or some other virtual function - even an explicit anchor as we have

Hi. The platform is an x86 32-bit machine running LLVM 2.4. I am trying to analyze Alias Analysis queries, and towards this end, I am trying to print out the "Value"s that form the queries. While trying to print these queries, llvm hits a segmentation fault. The fault is due to a Value which does not have its module set properly. I am using the operator<< to call the

It also occurs on several (different) test cases. I have founded that assershion rises in void ValueHandleBase::ValueIsDeleted(Value *V); Code from function: // All callbacks, weak references, and assertingVHs should be dropped by now. if (V->HasValueHandle) { #ifndef NDEBUG // Only in +Asserts mode... dbgs() << "While deleting: " << *V->getType()

On Fri, Sep 11, 2009 at 9:57 AM, Chris Lattner <clattner at apple.com> wrote: > Devang's work on debug info prompted this, thoughts welcome: > http://nondot.org/sabre/LLVMNotes/ExtensibleMetadata.txt Here is partial initial implementation. Thoughts ? - Devang -------------- next part -------------- A non-text attachment was scrubbed... Name: mdn.diff Type: application/octet-stream

...ation module, but it >>>> didn’t work out since Linker was not designed to work with different >>>> LLVMContexts for source vs destination. >>>> 2> removeUnusedMDNodes checks if a MDNode is used in a different way >>>> (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes >>>> that form cycles. >>>> >>> >>> 3) Make the MDNode be owned by the module that uses it? >>> >> >> MDNode is shared among modules so multiple modules can use it, if we >> specify an owner for...

I’ve been playing around with optimizing performance various passes and noticed something about ADCE: it keeps an Alive set that requires a lot of upkeep time-wise, but if each instruction had a /single bit/ of side data (to represent liveness, solely within the pass), the set wouldn’t be needed. I tested this out and observed a ~1/3 reduction in time in ADCE: 1454ms to 982ms according to a

We knew the day when we needed another FMF bit was coming back in: https://reviews.llvm.org/D39304 ...it was just a question of 'when'. :) I'm guessing that an FTZ bit won't be the last new bit needed if we consider permutations between strict FP and fast-math. Even without that, denormals-as-zero (DAZ) might also be useful? So rather than continuing to carve these out bit-by-bit,

...ation module, but it >>>> didn’t work out since Linker was not designed to work with different >>>> LLVMContexts for source vs destination. >>>> 2> removeUnusedMDNodes checks if a MDNode is used in a different way >>>> (i.e use_empty() && !hasValueHandler()), but it does not remove MDNodes >>>> that form cycles. >>>> >>> >>> 3) Make the MDNode be owned by the module that uses it? >>> >> >> MDNode is shared among modules so multiple modules can use it, if we >> specify an owner for...

Thanks, but I replaceAllUsesWith() - works well, but I still get bug in eraseFromParent(): While deleting: i32 (%class.B*, i32)* %_ZN1B1xEi An asserting value handle still pointed to this value! UNREACHABLE executed at /Users/neonomaly/LLVM/LLVM/lib/VMCore/Value.cpp:561! Yours sincerely, Kadysev Mikhail 21.04.2012, в 23:45, Nick Lewycky написал(а): > Михаил wrote: >> How correctly