Displaying 3 results from an estimated 3 matches for "hwport0156".
Did you mean:
hwport015
2020 May 10
2
[llvm-mca] Resource consumption of ProcResGroups
...crash when resource
> groups overlap without all atomic subunits being specified:
>
> `echo 'fxrstor (%rsp)' | llvm-mca -mtriple=x86_64-unknown-unknown
> -march=x86-64 -mcpu=haswell`
> crashes (because fxrstor requests
> `HWPort0,HWPort6,HWPort23,HWPort05,HWPort06,HWPort15,HWPort0156`, so
> HWPort0156 ends up asserting because 0,1,5, and 6 are all taken), so I
> added:
> ```
> --- a/llvm/lib/MCA/HardwareUnits/ResourceManager.cpp
> +++ b/llvm/lib/MCA/HardwareUnits/ResourceManager.cpp
> @@ -292,7 +292,7 @@ void ResourceManager::issueInstruction(
> ResourceSta...
2020 May 09
2
[llvm-mca] Resource consumption of ProcResGroups
Hi,
I’m trying to work out the behavior of llvm-mca on instructions with ProcResGroups. My current understanding is:
When an instruction requests a port group (e.g., HWPort015) and all of its atomic sub-resources (e.g., HWPort0,HWPort1,HWPort5), HWPort015 is marked as “reserved” and is issued in parallel with HWPort0, HWPort1, and HWPort5, blocking future instructions from reserving HWPort015
2020 May 10
2
[llvm-mca] Resource consumption of ProcResGroups
> On May 9, 2020, at 5:12 PM, Andrea Di Biagio via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> The llvm scheduling model is quite simple and doesn't allow mca to accurately simulate the execution of individual uOPs. That limitation is sort-of acceptable if you consider how the scheduling model framework was originally designed with a different goal in mind (i.e. machine