search for: valuehandl

...e target-specific "MipsCCState" and "MipsCallLowering::MipsHandler" to handle Call/Arguments/Return lowering. For RISCV, there's no "CCAssignFnForCall" or "CCAssignFnForReturn" functions defined, just like the solution in Mips, a new target-specific "ValueHandler" will be created to support calllowering. I have made some experiment that trying to implement the "LowerReturn" function, and it can return correctly. The code snippet may be as follows: ... CCState CCInfo(F.getCallingConv(), F.isVarArg(), MF, ArgLocs, F.getContext()); TLI.a...

...ef causes no test to fail. =/ Fortunately, putting an assert here *does* trip in the regression test suite, so the code is reached, just not exercised. Either way, the use case for the deleteValue at least makes perfect sense. But there is (IMO) a much better way to accomplish the same task: use a ValueHandle to trigger the update on deletion. This will prevent widespread failure to use the deleteValue API to update alias analysis. So I would like to replace deleteValue with a ValueHandle approach. But I'm more than a little nervous implementing this, *as no test actually uses the behavior*! At le...

...* trip in the > > regression > > test suite, so the code is reached, just not exercised. > > > > > > Either way, the use case for the deleteValue at least makes perfect > > sense. But there is (IMO) a much better way to accomplish the same > > task: use a ValueHandle to trigger the update on deletion. This > > will > > prevent widespread failure to use the deleteValue API to update > > alias analysis. So I would like to replace deleteValue with a > > ValueHandle approach. But I'm more than a little nervous > > implementing thi...

...ge pattern in one of the LLVM headers and we were wondering if that was expected or if it should be fixed. Namely the problem looks like this: #ifndef NDEBUG // Define some variable. #endif assert(/*use this variable, i.e., outside of the ifndef NDEBUG scope*/); This happens in include/llvm/IR/ValueHandle.h for the variable Poisoned line 494 This works because when we build LLVM with assert we explicitly disable NDEBUG: if( LLVM_ENABLE_ASSERTIONS ) […] # On non-Debug builds cmake automatically defines NDEBUG, so we # explicitly undefine it: if( NOT uppercase_CMAKE_BUILD_TYPE STREQUAL &quot...

...eserve AA or not is irrelevant, GlobalsModRef will be preserved anyways! =[[[[ So the only way to make things work correctly is to make GlobalsModRef survive *any* per-function changes to the IR. We cannot rely on AA updates at all. Most of the updates that GlobalsModRef needs can be provided by a ValueHandle now that we have them. This will prevent ABA-style issues in its caches, etc. I plan to send out a patch soon that switches it over to this strategy. It is also relying on a precomputed set of global variables whose address is never used by an instruction other than some very small set (gep, bitc...

...0x00007f1908c98cc9 gsignal + 57 >> 5 libc.so.6 0x00007f1908c9c0d8 abort + 328 >> 6 opt 0x000000000170cddd >> llvm::llvm_unreachable_internal(char const*, char const*, unsigned int) >> + 461 >> 7 opt 0x000000000137bd3b >> llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 1051 >> 8 opt 0x000000000137b5db llvm::Value::~Value() + 43 >> 9 opt 0x0000000001322319 llvm::CallInst::~CallInst() + 9 >> 10 opt 0x000000000131e676 >> llvm::Instruction::eraseFromParent() + 86 >&g...

...peIterator.h" #include "llvm/IR/InstrTypes.h" #include "llvm/IR/Instructions.h" +#include "llvm/IR/IntrinsicInst.h" #include "llvm/IR/Module.h" #include "llvm/IR/Operator.h" +#include "llvm/IR/Statepoint.h" #include "llvm/IR/ValueHandle.h" #include "llvm/IR/ValueSymbolTable.h" #include "llvm/Support/Debug.h" @@ -570,6 +572,13 @@ static bool isDereferenceablePointer(const Value *V, const DataLayout *DL, return true; } + // For gc.relocate, look through relocations + if (const IntrinsicInst *I...

...were wondering if that was expected or if it should be fixed. > > Namely the problem looks like this: > #ifndef NDEBUG > // Define some variable. > #endif > > assert(/*use this variable, i.e., outside of the ifndef NDEBUG scope*/); > > This happens in include/llvm/IR/ValueHandle.h for the variable Poisoned line 494 > > This works because when we build LLVM with assert we explicitly disable NDEBUG: > if( LLVM_ENABLE_ASSERTIONS ) > […] > # On non-Debug builds cmake automatically defines NDEBUG, so we > # explicitly undefine it: > if( NOT upperc...

...above works, but it isn't directly usable in the current GlobalISel implementation. Very sensibly, GISel tries to both reuse existing calling convention implementations and to reduce duplicated code as much as possible. To this end, CallLowering::handleAssignments will create a CCState and use ValueHandler::assignArg to call a function of type CCAssignFn type. I see a couple of options: 1) Creating a new virtual method in GISel CallLowering that creates and initialises a CCState or custom subclass. Use that to support target-specific CCStates. 2) Try to remove the need for custom CCState altogethe...

...t impression, have a better idea. Ok, I will probably implement this solution so far. Or maybe there could be other solutions like for example somehow extending callback mechanism to handle updates of the basic block parent. Can you please suggest any ideas? I don't think that our current ValueHandle callbacks will give us this functionality. We'd need a new callback? I also think that existing callbacks cannot handle the case when block's parent is changed, so something new will be needed. AssumptionCache as I understand was designed to be self-updating, so maybe it would be nice to...

...pes.h" >> #include "llvm/IR/Instructions.h" >> +#include "llvm/IR/IntrinsicInst.h" >> #include "llvm/IR/Module.h" >> #include "llvm/IR/Operator.h" >> +#include "llvm/IR/Statepoint.h" >> #include "llvm/IR/ValueHandle.h" >> #include "llvm/IR/ValueSymbolTable.h" >> #include "llvm/Support/Debug.h" >> @@ -570,6 +572,13 @@ static bool isDereferenceablePointer(const Value >> *V, const DataLayout *DL, >> return true; >> } >> + // For gc.relocate, look...

...y passes that would be affected and we > could "easily" make this happen. Hide the constructors and destructors > so that only the friend API can access it. Right, this is what MLIR does. However, keep in mind that this is just one piece of the puzzle. You also have things like ValueHandles which get owned by IPA passes. The CallGraph used by the inline persists across function pass manager runs, and needs to be correctly updatable in order to run CallGraphSCC passes. Getting to a multithread clean optimizer is not one bug fix away - this is a multiyear journey, and I would prefer...

Hi all, We have recently encountered a problem with AssumptionCache that it does not get updated when a block with llvm.assume calls gets outlined by the CodeExtractor. As a result we end up with stale references to the llvm.assume calls that were moved to the outlined function in the parent function's cache. The problem can be reproduced on the attached file as follows (many thanks to Andy

...isn't directly usable in the current GlobalISel > implementation. Very sensibly, GISel tries to both reuse existing calling > convention implementations and to reduce duplicated code as much as possible. > To this end, CallLowering::handleAssignments will create a CCState and use > ValueHandler::assignArg to call a function of type CCAssignFn type. > > I see a couple of options: > 1) Creating a new virtual method in GISel CallLowering that creates and > initialises a CCState or custom subclass. Use that to support target-specific > CCStates. > 2) Try to remove the need...

...of GloblasModRef. > > Ok, but we need performance information to make sure this doesn’t > cause a regression in practice for LTO builds. For example, Spec 2K > and 2K6 are a reasonable place to start. > > > 1) Fix obvious issues with GloblasModRef and switch it to > > ValueHandles > > 2) Mail out a patch to disable this part of GlobalsModRef. I can > > put it behind a flag or however folks would like it to work. > > 3) Remove addEscapingUse() update API, which without #2 may regress > > some LTO test case I don't have (because I don't have a...

...tly usable in the current GlobalISel >> implementation. Very sensibly, GISel tries to both reuse existing calling >> convention implementations and to reduce duplicated code as much as possible. >> To this end, CallLowering::handleAssignments will create a CCState and use >> ValueHandler::assignArg to call a function of type CCAssignFn type. >> >> I see a couple of options: >> 1) Creating a new virtual method in GISel CallLowering that creates and >> initialises a CCState or custom subclass. Use that to support target-specific >> CCStates. >> 2...

...e current GlobalISel >>> implementation. Very sensibly, GISel tries to both reuse existing calling >>> convention implementations and to reduce duplicated code as much as possible. >>> To this end, CallLowering::handleAssignments will create a CCState and use >>> ValueHandler::assignArg to call a function of type CCAssignFn type. >>> >>> I see a couple of options: >>> 1) Creating a new virtual method in GISel CallLowering that creates and >>> initialises a CCState or custom subclass. Use that to support target-specific >>>...

...limination.cpp (revision 81219) +++ lib/Transforms/Scalar/DeadStoreElimination.cpp (working copy) @@ -30,6 +30,8 @@ #include "llvm/Target/TargetData.h" #include "llvm/Transforms/Utils/Local.h" #include "llvm/Support/Compiler.h" +#include "llvm/Support/ValueHandle.h" + using namespace llvm; STATISTIC(NumFastStores, "Number of stores deleted");

On Mon, Mar 1, 2010 at 7:29 PM, Bill Wendling <wendling at apple.com> wrote: > On Feb 28, 2010, at 11:11 AM, Jianzhou Zhao wrote: > >> Hi, >> >> Given an instruction ptr instr, and a Function ptr func, >> can I simply check if func == instr->get_parent()->get_parent() to see if >> this instruction is still in this Function? >> > Yup! Well.

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() << &qu...