similar to: [LLVMdev] Question on instruction itineraries

On Mon, Aug 15, 2011 at 4:03 PM, Miguel G <miguel at esenciatech.com> wrote: > Hi everyone > I'm fairly new with LLVM and I've been searching around but couldn't find > info on this subject. > I started working on a target for a new cpu and I realizing my initial > simple understanding of instruction itineraries may be completely off. > I'm trying to model a

Thanks Eli. Somehow I was assuming the scheduler would insert NOPs to enforce latencies The CPU I'm dealing with doesn't automatically stall, i.e. latency must be ensured by the program. As an alternative to a pass, is it feasible to modify the scheduler to do so (optionally) or it would be too complicated. If possible, what would be the right place to look ? Thanks so much Miguel On

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

Hello, this is a very dump question, I hope to do more valuable question soon, but for now I'm just trying to run a simple hello world in C for clang and llvm to the target mblaze, but is not working. ( I need to change the compiler in the next stage) I past all the weekend tried to run this, and I was unable, I did the build of llVM/clang, but no bin was generate, only silly folder that I

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

Thanks Hal. On Fri, Oct 28, 2011 at 2:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > Carter, > > In my opinion (and I was the one who committed the changes in question), > it depends on the hardware. The pipeline descriptions are for the PPC > 440, which is an embedded PPC chip use in a variety of places. As such, > it is a fairly specific target, and using

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

Carter, In my opinion (and I was the one who committed the changes in question), it depends on the hardware. The pipeline descriptions are for the PPC 440, which is an embedded PPC chip use in a variety of places. As such, it is a fairly specific target, and using pipeline-hazard-based scheduling for specific embedded targets is not uncommon. The backends for ARM and MBlaze have similar pipeline

I hope you don't mind if do have a follow up question- is code in place in the code generation supporting "proper" scheduling via the processor itineraries in LLVM? On Fri, Oct 28, 2011 at 8:47 PM, Carter Cheng <cartercheng at gmail.com> wrote: > Thanks Hal. > > On Fri, Oct 28, 2011 at 2:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > >> Carter,

Hello, I was looking over some of the Target commits. I did notice some detailed pipeline descriptions in the ppc backends. I havent noticed anything in the literature describing this technique. Is this a standard approach for mapping SSA to hardware? Thanks in advance, Carter. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Sorry if this is a duplicate: I tried to send it last night and it didn't go through. I'm trimming some text to see if it helps. I have a simple program that fails on the Microblaze: int main() { unsigned long long x, y; x = 100; y = 0x8000000000000000ULL; return !(x > y); } As you can see, the test case compares two unsigned long long values. To try to track

Hi, Akira, I found you maintain mips MipsSchedule.td. does it correct? in MipsSchedule.td, every InstrItinData only uses one InstrStage. there's no ByPass info out there. are you sure this reflects the real R4xxx/R5xxx processors. why IILoad uses funcition unit ALU? InstrItinData<IILoad , [InstrStage<3, [ALU]>]> for my previous question, I have new input after

Hello, I am trying to improve lib/Target/Mips/MipsDelaySlotFiller.cpp by substituting nops emitting with instructions reordering. I need a hazard recognizer, but I haven't found any. Do I have to create one, or looking bad and there is any? Thanks for any reply. -- Filip Kocina, student FIT Email: xkocin00 at stud.fit.vutbr.cz

Akira, Thanks you for response. I understand Post-RA schedule make uses of scoreboardHazardRecognizer. But I found mips codes are good enough by default. basically, I can not easily eyeball any bubbles. I don't understand how they can do that without post-RA-sched. pre-ra-scheduler eg. (SelectionDAG/ScheduleDAGRRList.cpp) has little information and they can only schedule node in topology

On Fri, 26 Aug 2016, Peter Griffin wrote: > slim core is used as a basis for many IPs in the STi > chipsets such as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other device drivers > such as fdma, or demux whose IP is based around a slim core. > The

On Fri, 26 Aug 2016, Peter Griffin wrote: > slim core is used as a basis for many IPs in the STi > chipsets such as fdma and demux. To avoid duplicating > the elf loading code in each device driver a slim > rproc driver has been created. > > This driver is designed to be used by other device drivers > such as fdma, or demux whose IP is based around a slim core. > The

Hi Vinod, Bjorn, Patrice, This patchset adds support for the Flexible Direct Memory Access (FDMA) core found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU with a dedicated firmware. It is a general purpose DMA controller supporting 16 independent channels and data can be moved from memory to memory or between memory and paced latency critical real time targets. After quite

Hi Vinod, Bjorn, Patrice, This patchset adds support for the Flexible Direct Memory Access (FDMA) core found on STi chipsets from STMicroelectronics. The FDMA is a slim core CPU with a dedicated firmware. It is a general purpose DMA controller supporting 16 independent channels and data can be moved from memory to memory or between memory and paced latency critical real time targets. After quite

Is there a way to convert between SchedMachineModel and Itineraries? I was trying to write a very simple VLIW packetizer (Hexagon was my starting point). It turns out that current DFAPacketizer is using itineraries, but my schedule is based on SchedMachineModel (I was recommended to use it since the itineraries are being phased out). I was wondering if there is an automated tool that would

All, I am working on a scheduler for X86 and would like to include instruction latencies. It appears that this information is gathered from instruction itineraries, but that there isn't an itinerary for X86. I also can't seem to find documentation on how to add this for X86. Any pointers would be helpfull. Aran -------------- next part -------------- A non-text attachment was