search for: getunits

Here is the code <https://github.com/llvm-mirror/llvm/blob/c68dcdb413079d92118839dbd835e125293f411a/include/llvm/MC/MCInstrItineraries.h#L75> for InstrStage::getUnits() /// \brief Returns the choice of FUs. unsigned getUnits() const { return Units_; } This method returns an integer. How does one interpret it? As far as I see it it should tell me what resources are used by a given stage but I can't figure out what a return value means. Would anyone care to...

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer

Hi David If you look at line https://github.com/llvm/llvm-project/blob/master/llvm/lib/IR/Verifier.cpp#L1160 there is IR verification which asserts that only in case of `spFlags = DISPFlagDefinition`, the compilation unit (`unit` field) should be present. Otherwise, it should *not* be present. In the crash case, `spFlags = DISPFlagOptimized`. So, I guess, `unit` field should *not* be present,

Hi- Here is the simple C++ function: ----------- void foo() { } ----------- Let's say, above function is compiled to generate LLVM IR with -g flag using the command line `clang++ -g -O0 -S -emit-llvm foo.cpp`, we get below IR ----------- ; ModuleID = 'foo.cpp' source_filename = "foo.cpp" target datalayout =

I am bit confused - `unit` must be present for definitions, and `optimized ` is also a `definition`, so, `unit` must be present for `optimized ` too. Am I right? Mahesha On Sun, May 31, 2020 at 10:14 PM David Blaikie <dblaikie at gmail.com> wrote: > definition and optimized are orthogonal (a function could be both, or > neither) - one says this DISubprogram describes a function

Let's forget about my malformed IR if it is adding additional confusion here. I mentioned it here to ease the conversation, but if it is causing confusion rather than making the discussion flow easier, then we better ignore it. The whole triggering point for this email initiative is - one of the applications is crashing with the stack trace that I mentioned earlier. The crash is during the

...s occupied by a MCInstrDesc and // change the current state to reflect that change. void DFAPacketizer::reserveResources(const llvm::MCInstrDesc *MID) { unsigned InsnClass = MID->getSchedClass(); const llvm::InstrStage *IS = InstrItins->beginStage(InsnClass); unsigned FuncUnits = IS->getUnits(); UnsignPair StateTrans = UnsignPair(CurrentState, FuncUnits); ReadTable(CurrentState); assert(CachedTable.count(StateTrans) != 0); CurrentState = CachedTable[StateTrans]; } This happens at the packetization stage, i.e. scheduling seems to work. My schedule description is not very differe...

Hi David, OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope. But how about that we are emitting a subprogram entry that has no attributes? 0x0000002b: DW_TAG_subprogram [3] * 0x0000002c: DW_TAG_typedef [4] DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040}) DW_AT_name [DW_FORM_strp] (

...If it doesn't, we ignore the instruction. >> + const MCInstrDesc& TID = MI->getDesc(); >> + unsigned SchedClass = TID.getSchedClass(); >> + const InstrStage* IS = ResourceTracker->getInstrItins()->beginStage(SchedClass); >> + unsigned FuncUnits = IS->getUnits(); >> + return !FuncUnits; >> +} >> + >> +// isSoloInstruction: - Returns true for instructions that must be >> +// scheduled in their own packet. >> +bool HexagonPacketizerList::isSoloInstruction(MachineInstr *MI) { >> + >> + if (MI->isInlineAsm...