Hi, I am having some trouble understanding the scheduling scheme for the C-A9. Looking at the ARMScheduleA9.td file I find this line that overrides the target SchedWrite with processor specific latencies. def : SchedAlias<WriteALU, A9WriteALU>; However, in this same file, I find the lines presented below, which are mapping the SchedReadWrite to, for example, the ANDri instruction. // ===---------------------------------------------------------------------===// // Subtarget-specific overrides. Map opcodes to list of SchedReadWrite types. // def : InstRW< [WriteALU], (instregex "ANDri", "ORRri", "EORri", "BICri", "ANDrr", "ORRrr", "EORrr", "BICrr")>; This same instruction is defined in the ARMInstrInfo.td as inheriting from AsI1_bin_irs (shown below) which, in turn, associates Sched<[WriteALU, ReadALU]> with the instruction. defm AND : AsI1_bin_irs<0b0000, "and", IIC_iBITi, IIC_iBITr, IIC_iBITsr, and, 1>; In my mind, we have latencies defined from the ProcessorItineraries, latencies defined in the SchedReadWrite representation which are mapped through SchedAlias to the ANDri and, in the end, a mapping (or overriding?) of the latencies in the Itineraries by the processor-specific SchedWrites, through the InstRW? Can someone share some light on what scheduling/lantecy information is being used in this case? I cannot get my head around this... What am I missing here? Note: I also do not understand why use instregex if we could use the IIC_* for the InstRW. Thanks. - Tiago -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180405/1e02e3c0/attachment.html>
I made a confusion with InstRW (overriding Sched information for specific instructions without modifying the InstrInfo.td) and ItinRW (mapping Sched data to Instruction Itineraries)... the names don’t make it easier to understand. My apologies. - Tiago 2018-04-05 15:51 GMT+02:00 Pedro Lopes <pedro.fraiao at gmail.com>:> Hi, > > I am having some trouble understanding the scheduling scheme for the C-A9. > > Looking at the ARMScheduleA9.td file I find this line that overrides the > target SchedWrite with processor specific latencies. > > def : SchedAlias<WriteALU, A9WriteALU>; > > However, in this same file, I find the lines presented below, which are > mapping the SchedReadWrite to, for example, the ANDri instruction. > > // ===--------------------------------------------------------- > ------------===// > // Subtarget-specific overrides. Map opcodes to list of SchedReadWrite > types. > // > def : InstRW< [WriteALU], > (instregex "ANDri", "ORRri", "EORri", "BICri", "ANDrr", "ORRrr", > "EORrr", > "BICrr")>; > > > This same instruction is defined in the ARMInstrInfo.td as inheriting from > AsI1_bin_irs (shown below) which, in turn, associates Sched<[WriteALU, > ReadALU]> with the instruction. > > defm AND : AsI1_bin_irs<0b0000, "and", > IIC_iBITi, IIC_iBITr, IIC_iBITsr, and, 1>; > > In my mind, we have latencies defined from the ProcessorItineraries, > latencies defined in the SchedReadWrite representation which are mapped > through SchedAlias to the ANDri and, in the end, a mapping (or overriding?) > of the latencies in the Itineraries by the processor-specific SchedWrites, > through the InstRW? > > Can someone share some light on what scheduling/lantecy information is > being used in this case? I cannot get my head around this... What am I > missing here? > > Note: I also do not understand why use instregex if we could use the IIC_* > for the InstRW. > > Thanks. > > - Tiago > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180406/6f8e2977/attachment.html>
Reasonably Related Threads
- Incorrect placement of an instruction after PostRAScheduler pass
- A question about AArch64 Cortex-A57 subtarget definition
- [LLVMdev] SchedMachineModel clarifications
- InstrItin and SchedWriteRes
- Base R wilcox.test gives incorrect answers, has been fixed in DescTools, solution can likely be ported to Base R