search for: valuehandler

...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.ana...

Greetings folks, As I'm working on refactoring the AA interfaces in LLVM to prepare for the new pass manager, I keep hitting issues. Some of the complexity that is hitting this stems from the update API, which consists of three virtual functions: deleteValue(Value *V) copyValue(Value *From, Value *To) addEscapingUse(Use &U) These interfaces are *very* rarely called. Here are the only

----- Original Message ----- > From: "Hal Finkel" <hfinkel at anl.gov> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Daniel Berlin" <dannyb at google.com> > Sent: Thursday, July 2, 2015 3:14:38 PM > Subject: Re: AliasAnalysis update interface - a tale

Hi, While audit our code, we found out a strange 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

Ok folks, I wrote up the general high-level thoughts I have about stateful AA in a separate thread. But we need to sort out the completely and horribly broken aspects of GlobalsModRef today, and the practical steps forward. This email is totally about the practical stuff. Now, as to why I emailed this group of people and with this subject, the only pass pipeline that includes GlobalsModRef, is

Hi, On 02/10/2016 01:23 AM, haicheng at codeaurora.org wrote: > Thank you, Mikael. I can reproduce what you saw and am looking into it. Great! > Just curious, why do you run loop-deletion before licm and loop-idiom? As part of our internal testing we use Csmith to generate C-programs and then we run the compiler with random generated compiler flags on that input. This bug was

I'm have a [PATCH] isDereferenceablePointer: look through gc.relocates and I want to know how to test this patch. So far, I've found one candiate: speculative execution in SimplifyCFG (test/Transforms/SimplifyCFG/SpeculativeExec.ll). However, it's somewhat involved to show that SimplifyCFG does kick in for gc.relocate. Is there a better way to directly test it? Signed-off-by:

Good point, I forgot to check the standard. Given the clang was failing I assumed the code was wrong x). I am guessing there is something weird with the project, because indeed, paragraph 7.2 of the standard says: The assert macro is redefined according to the current state of NDEBUG each time that <assert.h> is included. > On Oct 4, 2017, at 2:53 PM, Craig Topper <craig.topper at

...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 altogether....

Hi Hal, On 1/16/19 6:59 PM, Dmitriev, Serguei N via llvm-dev wrote: 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

Philip Reames wrote: > T.M.K., there's no direct way to test it. There is. See the 'unittests/' directory which contains the C++ unit tests. See unittests/IR/UserTest.cpp for an example that builds up IR from a .ll-in-a-C-string then queries C++ API operations on it. Nick You have to construct a > transformation which happens with the information you added and not >

> On Mar 26, 2020, at 8:26 AM, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > On 3/26/20 5:53 AM, Florian Hahn wrote: >>> It also doesn't solve the problem of Functions themselves -- those are >>> also GlobalValues… >> >> >> I am not sure why not. Function passes should only rely on the information at the callsite & from the

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 f...

----- Original Message ----- > From: "Chris Lattner" <clattner at apple.com> > To: "Chandler Carruth" <chandlerc at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov>, "Justin Bogner" > <mail at justinbogner.com>, "Duncan Exon Smith"

...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 >>> C...

Dear All, The LLVM 2.6 Release Branch doesn't compile for me on Mac OS X. The following patch seems to fix it (it adds a missing include file to get WeakVH defined). Has anyone else seen this breakage, or is it possible that I've got the wrong branch checked out? -- John T. Index: lib/Transforms/Scalar/DeadStoreElimination.cpp

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()