similar to: InstrStage, Interpretation of getUnits()

For some reason on my VLIW target DFAPacketizer fails at assert(CachedTable.count(StateTrans) != 0); in the following function: // reserveResources - Reserve the resources 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

In our architecture loads from certain memory locations take a long time to complete (on the order of 150 clock cycles). Since we don't have a way to tell at compile time if the address being loaded from lies in slow or fast memory, I've gone ahead and made all of the load numbers high, such as: InstrItinData< II_LOAD1, [InstrStage<150, [AGU]>]>, However, I see that

I overrode getInstrLatency and did some printing to see what is available there. It looks like the registers are still virtual at that point when getInstrLatency is called - is that correct? (we needed to make some decisions based on actual registers that have been assigned since some registers are reserved as address space pointers and we could vary the latency based on which address space

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,

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

On Oct 21, 2011, at 12:15 AM, James Molloy wrote: > Hi Andy, > > Could you describe how this would be done? In the current ARM itineraries > (say C-A9 for example), the superscalar issue stage is modelled as taking 1 > cycle. If it were to take 2 cycles instead, as far as I can tell the hazard > analyser would stall because both FU's would be acquired. > > I would

The scoreboard hazard detector that I've added for the PPC 440 is not detecting hazards as it should (which certainly could be my fault somehow, but...). For example, it will produce a schedule that looks like... SU(28): 0x127969b0: f64,ch = LFD 0x12793aa0, 0x1277b4f0, 0x127965b0<Mem:LD8[%scevgep100](tbaa=!"double")> [ORD=41] [ID=28] SU(46): 0x12796ab0: f64 = FADD 0x127969b0,

Jonas, At this point, the DFA packetizer models a simple VLIW architecture and does not accommodate multiple stages. That's the reason for the behavior you're seeing. -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation *From:*llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On Behalf Of *Jonas

Hi Jonas, > It is interesting to find this in the ARM backend, considering your answer. The ARM backend doesn't use the DFA packetizer. It's only used by Hexagon. At this point, there is no plan to address thisin the DFA packetizer since none of the supported targets needthe functionality. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

I'm unclear how does DFAPacketizer and the scheduler know a given instruction is a load. Here is what I'm talking about Let's assume my VLIW target is described as follows: def MyTargetItineraries : ProcessorItineraries<[Slot0, Slot1], [], [ .............................. InstrItinData<RI, [InstrStage<1, [Slot0, Slot1]>]>,

Hi, I looked a bit through the mail archives, and found this question answered in Oct 2011 (see below). It is interesting to find this in the ARM backend, considering your answer. Can you give more information about for example is this a temporary deficiency in the DFAPacketizer? What is the IIC_iMOVi itinerary doing below? Thanks, Jonas Thu Oct 6 15:11:25 CDT 2011: Hello Hal. > Is there

Hi Anshu, Would there be any interest in extending this algorithm to handling more extensive models, such as VLIW scheduling based on FU's and bundle space... ie handle multiple stages ? I might do it and commit, if there is acceptance and guidance... Jonas ________________________________ From: Anshuman Dasgupta [mailto:adasgupt at codeaurora.org] Sent: Tuesday, February 12, 2013 4:47 PM

I have an instruction that takes no operands, and produces two results, in two consecutive cycles. I tried both of the following to my Schedule.td file: InstrItinData<IIMyInstr, [InstrStage<2, [FuncU]>], [1, 2]>, InstrItinData<IIMyInstr, [InstrStage<1, [FuncU]>, InstrStage<1, [FuncU]>], [1, 2]>, From what I can see in examples, these say that the first

Hi llvm-dev, I wonder why there is an extra cycle for getOperandLatency. It doesn't seem intuitive. UseCycle = DefCycle - UseCycle + 1; When I read the comments in TargetItinerary.td, it said OperandCycles are optional "cycle counts". They specify the cycle after instruction issue the values which correspond to specific operand indices are defined or read. I thought if

In the example provided: // InstrItinData<IIC_iLoad_i , [InstrStage<1, [A9_Pipe1]>, // InstrStage<1, [A9_AGU]>], // [3, 1], [A9_LdBypass]>, If there is an operand dependency, does the scheduler assume that the instruction is held in A9_Pipe1 or in A9_AGU until the operand is ready? Thanks again, Hal On Fri,

Does anybody know how to specify instruction latency in the itinerary scheduling model? For some reason no matter what I do I get a latency of 1. -- Rail -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/161bd6cb/attachment.html>

On May 9, 2013, at 4:02 AM, Fraser Cormack <fraser at codeplay.com> wrote: > I have an instruction that takes no operands, and produces two results, in two consecutive cycles. > > I tried both of the following to my Schedule.td file: > > InstrItinData<IIMyInstr, [InstrStage<2, [FuncU]>], [1, 2]>, > InstrItinData<IIMyInstr, [InstrStage<1,