search for: funcinfo

Hi, In SelectionDAGISel::SelectAllBasicBlocks if (TM.Options.EnableFastISel) FastIS = TLI->createFastISel(*FuncInfo, LibInfo); followed by if (!FastIS) { LowerArguments(Fn); } else { The above implies that implementing FastIS is optional. In contrast to that, testing whether FastIS is actually been used is done by testing if TM.Options.EnableFastISel is set. For example in SelectionDAGISel::Lower...

...scriptors, which I by traversing the uses of poolinit and accessing the first argument of each call. I need to find the DSNode (in the original function) to which this pool descriptor corresponds. The rub is that this pool descriptor of course does not exist except in the clone. If I call getFuncInfo(), I get a NULL pointer. getFuncInfoOrClone() returns the original function's FuncInfo structure, but this function's DSNode <-> PoolDescriptor mapping will not have my pool descriptor in it because my pool descriptor only existed in the clone. I'm fine with the DSNode being...

...set, if we have debug information, we don't eliminate the unconditional branch instruction, otherwise we eliminate it. /// (fall-through) successor, and update the CFG. void FastISel::fastEmitBranch(MachineBasicBlock *MSucc, const DebugLoc &DbgLoc) { - if (FuncInfo.MBB->getBasicBlock()->size() > 1 && - FuncInfo.MBB->isLayoutSuccessor(MSucc)) { - // For more accurate line information if this is the only instruction - // in the block then emit it, otherwise we have the unconditional + if (FuncInfo.MBB->isLayoutSuccessor(MSucc)...

...deGenAndEmitDAG() { (void)BlockNumber; bool MatchFilterBB = false; (void)MatchFilterBB; #ifndef NDEBUG - MatchFilterBB = (!FilterDAGBasicBlockName.empty() && + MatchFilterBB = (FilterDAGBasicBlockName.empty() || FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str()); #endif — Mehdi > On Aug 1, 2015, at 11:07 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > Simply replacing the && with || did not fix the issue. This issue still exists after making those changes. There is maybe som...

...ase, and the @@ -412,6 +421,7 @@ // implemented with a libcall, etc. TargetLowering &TLI; SelectionDAG &DAG; + AliasAnalysis &AA; const TargetData *TD; /// SwitchCases - Vector of CaseBlock structures used to communicate @@ -424,8 +434,9 @@ FunctionLoweringInfo &FuncInfo; SelectionDAGLowering(SelectionDAG &dag, TargetLowering &tli, + AliasAnalysis &aa, FunctionLoweringInfo &funcinfo) - : TLI(tli), DAG(dag), TD(DAG.getTarget().getTargetData()), + : TLI(tli), DAG(dag), AA(aa), TD(DAG.getTarget()...

...f 3.6 and it looks like the fix wasn't merged. I don't have the revision number for the fix to hand but in lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, this: MatchFilterBB = (!FilterDAGBasicBlockName.empty() && FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str()); Should be: MatchFilterBB = (FilterDAGBasicBlockName.empty() || FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str()); The trunk has the correct code so the option should be...

Here it is: llc: SelectionDAGISel.cpp:358: virtual bool llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&): Assertion `FuncInfo->CatchInfoFound.size() == FuncInfo->CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. 0 libLLVM-2.7.so 0x0140e2c8 Stack dump: 0. Program arguments: llc -O0 bullet.linked.bc.opt 1. Running pass 'X86 DAG->DAG Instruction Selection...

...t I don't understand. After I insert a call to an externally defined function into an invoked function, llc spits out the following assertion failure when I compile the bytecode: llc: SelectionDAGISel.cpp:4912: virtual bool llvm::SelectionDAGISel::runOnFunction(llvm::Function&): Assertion `FuncInfo.CatchInfoFound.size() == FuncInfo.CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"' failed. I looked at the SelectionDAGISel.cpp code but I have no idea what the problem is or how I can fix it. I've tried setting different parameter attributes...

...original function and not any of its clones. Since the pool descriptor in question may very well only exist in a clone, I can't use this. Is there another way? Thanks, --Patrick Harmen van der Spek wrote: > You might want to have a look at PoolAllocate.h. > > Per function, a PA::FuncInfo structure keeps track of all DSNodes that > should be pool allocated. ArgNodes contains pool arguments, NodesToPA > contains nodes that are locally pool allocated and thus initialized > using poolinit. > > PoolDescriptors contains a mapping from DSNodes to pool descriptors, and &gt...

Hi Patrick, That's right. DSNodes are coupled to the original function. For function clones, you first need to get the original function, and then use the DSNode from that function. FuncInfo contains the information if a function is a clone and what the original function is. If you want to find the corresponding DSNode for some instruction, you must call PA::FuncInfo::MapValueToOriginal( value ) Then you can get the DSNode from the DSGraph: llvm::DSNodeHandle handle = _dsg-&g...

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com> wrote: > So this seems to be the cause of the problem. I guess you're mixing two different problems. First, is the possible lack of conformance with the ABI you state, which I can't comment since I don't know that ABI very well. Second, is the fact that clang is not printing correct debug information (or is

...ads with CatchInfoLost > and CatchInfoFound and make sure they're all handled. However, > lowerinvoke throws a wrench into that by getting rid of the explicit > invokes, so SelectionDAGISel never identifies any landing pads, and > then complains with: > Assertion failed: (FuncInfo->CatchInfoFound.size() == FuncInfo- > >CatchInfoLost.size() && "Not all catch info was assigned to a > landing pad!"), function runOnFunction, file /Volumes/Home/grosbaj/ > sources/llvm-public/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, > line 350. the...

Hi Ankur, > The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( > "llc -help" doesn't list it ). as far as I remember, displaying DAGs during compilation is only enabled in "debug builds" [1] of LLVM. You probably have to re-configure and re-compile LLVM to enable this feature. Best regards, Christoph [1]

...;t > merged. I don't have the revision number for the fix to hand but in > lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, this: > > MatchFilterBB = (!FilterDAGBasicBlockName.empty() && > > FilterDAGBasicBlockName == > > FuncInfo->MBB->getBasicBlock()->getName().str()); > > Should be: > > MatchFilterBB = (FilterDAGBasicBlockName.empty() || > > FilterDAGBasicBlockName == > > FuncInfo->MBB->getBasicBlock()->getName().str()); > > > &...

...deGenAndEmitDAG() { (void)BlockNumber; bool MatchFilterBB = false; (void)MatchFilterBB; #ifndef NDEBUG - MatchFilterBB = (!FilterDAGBasicBlockName.empty() && + MatchFilterBB = (FilterDAGBasicBlockName.empty() || FilterDAGBasicBlockName == FuncInfo->MBB->getBasicBlock()->getName().str()); #endif — Mehdi On Aug 1, 2015, at 11:07 AM, Ryan Taylor <ryta1203 at gmail.com<mailto:ryta1203 at gmail.com>> wrote: Simply replacing the && with || did not fix the issue. This issue still exists after making those changes...

...perate to track landing pads with CatchInfoLost and CatchInfoFound and make sure they're all handled. However, lowerinvoke throws a wrench into that by getting rid of the explicit invokes, so SelectionDAGISel never identifies any landing pads, and then complains with: Assertion failed: (FuncInfo->CatchInfoFound.size() == FuncInfo- >CatchInfoLost.size() && "Not all catch info was assigned to a landing pad!"), function runOnFunction, file /Volumes/Home/grosbaj/ sources/llvm-public/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp, line 350. Is it reasonable to exp...

I am trying to understand the SelectionDAG construction from LLVM IR. I have gone through the doc "The LLVM Target-Independent Code Generator" on LLVM site. This gives a great initial overview. However I am unable to catch the actual control flow for the llvm->selectionDag conversion. The flags "-view-sched-dags".. described in the doc doesn't seem to work. ( "llc

It seems that fast-isel for intel does not handle strlen. It's a general problem in fast-isel . ~/llvmw/build/Deb~/llvmw/build/Debug+Asserts/bin/clang -O0 -mllvm -fast-isel-verbose -mllvm -fast-isel strlen1.c strlen1.c:12:3: warning: implicitly declaring library function 'printf' with type 'int (const char *, ...)' printf("%i\n", len); ^

...he correct approach for what you are doing. If, for example, you need to know whether a pool is a type-homogeneous, then an easier method would be to modify poolinit() to pass an argument containing DSNode information (such as a flag indicating type-homogeneity). -- John T. > If I call getFuncInfo(), I get a NULL pointer. getFuncInfoOrClone() > returns the original function's FuncInfo structure, but this function's > DSNode <-> PoolDescriptor mapping will not have my pool descriptor in it > because my pool descriptor only existed in the clone. I'm fine with th...

Hi Chandler, That's embarrassing how weird this part of clang is. I have a provisional patch which fixes the problem but underlines clang's problems. I will submit it tonight for comments. суббота, 18 октября 2014 г. пользователь Chandler Carruth написал: > > On Fri, Oct 17, 2014 at 7:51 AM, Anton Korobeynikov < > anton at korobeynikov.info >