search for: lsunit

...st. > - Number of temporary registers available for renaming. See MicroOpBufferSize above. > - Number of read/write ports in the register file(s). The assumption is that we hit micro-op issue width first. I suppose it’s good to have though. > - Length of the load/store queue in the LSUnit. That was supposed to be covered by per-processor-resource buffer size. Maybe you want to simulate the load/store queue differently from other functional units? e.g. one shared queue across multiple load store units? > It is also very difficult to find a "good" abstract model to desc...

...g in scheduling models are: - Maximum number of instructions retired per cycle. - Actual dispatch width (it often differs from the issue width). - Number of temporary registers available for renaming. - Number of read/write ports in the register file(s). - Length of the load/store queue in the LSUnit. It is also very difficult to find a "good" abstract model to describe the behavior of out-of-order processors. So, we have to keep in mind that all of these aspects are going to affect the quality of the static analysis performed by the tool. An extensive list of known limitations is r...

...ove. > Right. This can be another detail that targets could expose. > - Number of read/write ports in the register file(s). > > > The assumption is that we hit micro-op issue width first. I suppose it’s > good to have though. > > - Length of the load/store queue in the LSUnit. > > > That was supposed to be covered by per-processor-resource buffer size. > Maybe you want to simulate the load/store queue differently from other > functional units? e.g. one shared queue across multiple load store units? > Yes. To start, I'd like to be able to have a un...

...e: >  - Maximum number of instructions retired per cycle. >  - Actual dispatch width (it often differs from the issue width). >  - Number of temporary registers available for renaming. >  - Number of read/write ports in the register file(s). >  - Length of the load/store queue in the LSUnit. > > It is also very difficult to find a "good" abstract model to describe the > behavior of out-of-order processors. So, we have to keep in mind that > all of > these aspects are going to affect the quality of the static analysis > performed > by the tool. > &gt...

...e: > - Maximum number of instructions retired per cycle. > - Actual dispatch width (it often differs from the issue width). > - Number of temporary registers available for renaming. > - Number of read/write ports in the register file(s). > - Length of the load/store queue in the LSUnit. > *And a few more when simulating the frontend. Note however, that the frontend actually requires a lot less information because it’s mostly agnostic to individual instructions. We basically only need the lengths of a few queues. * > > It is also very difficult to find a "good&quot...

...into account the cache hierarchy. Does this mean that the tool assumes all the loads/stores hit the L1 cache? As you pointed out, MCA does not really model the cache hierarchy. You might want to take a look at the Load/Store unit documentation as well: http://llvm.org/doxygen/classllvm_1_1mca_1_1LSUnit.html You probably already saw this from the CommandGuide for llvm-mca, but I’ll repeat it here: “The LSUnit does not attempt to predict if a load or store hits or misses the L1 cache. It only knows if an instruction “MayLoad” and/or “MayStore.” For loads, the scheduling model provides an “optimist...

...> Does this mean that the tool assumes all the loads/stores hit the L1 cache? > > > > As you pointed out, MCA does not really model the cache hierarchy. You > might want to take a look at the Load/Store unit documentation as well: > http://llvm.org/doxygen/classllvm_1_1mca_1_1LSUnit.html > > > > You probably already saw this from the CommandGuide for llvm-mca, but I’ll > repeat it here: > > “The LSUnit does not attempt to predict if a load or store hits or misses > the L1 cache. It only knows if an instruction “MayLoad” and/or “MayStore.” > For loads...

Hi All, I would like to use llvm-mca to estimate the IPC of a given code region. I am interested in the library version (https://reviews.llvm.org/D50929?id=162210 <https://reviews.llvm.org/D50929?id=162210>) but I have troubles understanding how to use it. Could you please point me to some documentations or (better) some code examples if any? Reading the documentation

...isImplicit()) continue; >> diff --git a/lib/Target/Hexagon/HexagonSchedule.td b/lib/Target/Hexagon/HexagonSchedule.td >> index fbea445..c488796 100644 >> --- a/lib/Target/Hexagon/HexagonSchedule.td >> +++ b/lib/Target/Hexagon/HexagonSchedule.td >> @@ -13,7 +13,6 @@ def LSUNIT : FuncUnit; >> def MUNIT : FuncUnit; >> def SUNIT : FuncUnit; >> >> - >> // Itinerary classes >> def ALU32 : InstrItinClass; >> def ALU64 : InstrItinClass; >> @@ -24,23 +23,25 @@ def LD : InstrItinClass; >>...