search for: noophazard

...tive instructions that are separated in the final ASM listing and they should not. I also tried the standard pre-RA scheduler, implemented in lib/CodeGen/ScheduleDAGRRList.cpp, (with a ScoreboardHazardRecognizer), but even if I report that I have a data hazard in getHazardType() and return NoopHazard, the scheduler will not insert a NOP instruction in the respective place where I report the hazard . For me it is more convenient, in principle, to use the pre-RA scheduler, but it is not generating NOPs. Could you please tell me how can I generate NOPs with a pre-RA scheduler when I am al...

...s stated in my first email, for example, I have a store instruction that is storing the value updated by the instruction immediately above, which is NOT ok, since for my processor this is a data hazard and in this case I have to insert a NOP in between by making getHazardType() to: return NoopHazard; // this basically emits noop However, to my surprise, my very simple post-RA scheduler (using my class derived from ScoreboardHazardRecognizer) is cycling FOREVER after this return NoopHazard, by calling getHazardType() again and again for this SAME store instruction I found in the first...

...lo. I am progressing a bit with difficulty with the post RA scheduler (PostRASchedulerList.cpp with ScoreboardHazardRecognizer) - the problem I have is that it doesn't advance at the next available instruction when the overridden ScoreboardHazardRecognizer::getHazardType() method returns NoopHazard and it gets stuck at the same instruction (store in my runs). Just to make sure: I am trying to use the post-RA (Register Allocation) scheduler to avoid data hazards by inserting, if possible, other USEFUL instructions from the program instead of (just) NOPs. Is this out-of-order scheduling...

...ly a method: HazardType getHazardType(SUnit *SU, int Stalls); In this method I check if the current SU is a vector store and the previous instruction updates the register used by the store, which in my processor is a data hazard, in which case I give: return NoopHazard; and otherwise, I give: return ScoreboardHazardRecognizer::getHazardType(SU, Stalls); - I implemented in [Target]InstrInfo.cpp 2 more methods: - CreateTargetPostRAHazardRecognizer() to register the [Target]DispatchGroupSBHazardRecognizer()...

Hello. I see there is little information on specifying instructions with delay slots. So could you please tell me how can I insert NOPs (BEFORE or after an instruction) or how to make an aware instruction scheduler in order to avoid miscalculations due to the delay slot effect? More exactly, I have the following constraints on my (SIMD) processor: - certain stores or

...king, Scheduling, Unpacking) Assembly Printer In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. Within my back-end I added a...

Hi, I'm not a compiler expert, so this is a basic questions. I'm trying to get some new instruction scheduling code working, and I'm trying to do things as simply as possible in the initial prototype. Looking through the code it looks like only PPC architecture can return NoopHazard, and I'm not interested in PPC. If in addition I'm preventing avoidable stalls by different means, that means I can completely ignore the HazardRecognizer and CurCycle (for now)? Many thanks for any help, David Steven Tweed

...packing) > Assembly Printer > > > In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. > > Within my back-end...

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

Hi all, here is the current (unfinished) version of the VLIW support I mentioned. It is a patch over svn rev 141176. It includes the MachineInstrBundle class, and small required changes in a couple of outside LLVM files. Also includes a modification to Mips target to simulate a 2-wide VLIW MIPS. The scheduler is really silly, I did not want to implement a scheduler, just the bundle class, and

...packing) > Assembly Printer > > > In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. > > Within my back-end...

...; Assembly Printer >> >> >> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >> >> Within my...

...; Assembly Printer >> >> >> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >> >> Within my...

...rinter >>> >>> >>> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >>> >>> Wi...

...t; > >> > >> In principle, it is possible to use the LLVM scheduler to generate > parallel code by providing a custom hazard recognizer that checks true data > dependencies of the current bundle. The scheduler has also the capability to > output NEXT operations by using NoopHazard and outputting a NEXT instruction > instead of a NOP. However, the scheduler that is used within "DAG->DAG > Pattern Instruction Selection" uses this glue mechanism and that could be > problematic since no NEXT instructions are issued between glued > instructions. > >...

...gt; Assembly Printer >> >> >> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >> >> Within my b...

...t; > >> > >> In principle, it is possible to use the LLVM scheduler to generate > parallel code by providing a custom hazard recognizer that checks true data > dependencies of the current bundle. The scheduler has also the capability to > output NEXT operations by using NoopHazard and outputting a NEXT instruction > instead of a NOP. However, the scheduler that is used within "DAG->DAG > Pattern Instruction Selection" uses this glue mechanism and that could be > problematic since no NEXT instructions are issued between glued > instructions. > >...

...rinter >>> >>> >>> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >>> >>> Wi...

...gt; >>>> In principle, it is possible to use the LLVM scheduler to generate >> parallel code by providing a custom hazard recognizer that checks true data >> dependencies of the current bundle. The scheduler has also the capability to >> output NEXT operations by using NoopHazard and outputting a NEXT instruction >> instead of a NOP. However, the scheduler that is used within "DAG->DAG >> Pattern Instruction Selection" uses this glue mechanism and that could be >> problematic since no NEXT instructions are issued between glued >> instruc...

...gt;>> >>>> >>>> In principle, it is possible to use the LLVM scheduler to generate parallel code by providing a custom hazard recognizer that checks true data dependencies of the current bundle. The scheduler has also the capability to output NEXT operations by using NoopHazard and outputting a NEXT instruction instead of a NOP. However, the scheduler that is used within "DAG->DAG Pattern Instruction Selection" uses this glue mechanism and that could be problematic since no NEXT instructions are issued between glued instructions. >>>> >>&gt...