https://bugs.kde.org/show_bug.cgi?id=369509
--- Comment #7 from ahashmi <assad.has...@linaro.org> ---
> The 413547 patch does the hw capabilities detection needed to decide
> which regtests to run, and it looks like you've successfully added the
> relevant bits for AArch64. But it doesn't do those tests for Valgrind
> itself, hence V has no way to know whether the host has (eg) 8.1
> support and so whether guest_arm64_toIR.c should decode 8.1
> instructions. So far you've gotten away with "down translating" 8.1 on
> the guest side to 8.0 on the host side. But that's not a long-term
> solution.
That's fine. I agree that "down translating" to v8.0 is not a long-term
solution but for now it's adequate.
I'm assuming that in "down translating" or ("lowering" in the LLVM
compiler's codegen terminology), we don't lose any functionality as far
as tools are concerned, i.e. lowering IR for v8.0 code generation does
not mask or disable any tools features AS LONG AS we lower each
instruction correctly.
> What needs to happen is:
> * add VEX_HWCAPS_ARM64_whatever constants (see existing definitions)
> * add code in VG_(machine_get_hwcaps) to query the host's capabilities.
> The relevant capabilities description is eventually passed to
> disInstr_ARM64, which can use it to choose whether to decode or not
> decode an instruction.
That's fine. I can't see any VEX_HWCAPS_ARM64_whatever just
VEX_HWCAPS_ARM_whatever so these will be all new for AArch64.
> For the definitions of VEX_HWCAPS_ARM64_* that you want, I suggest
> looking at VEX_HWCAPS_AMD64_* as examples. But for actually detecting
> capabilities in VG_(machine_get_hwcaps), I suggest you use the
> signal-longjmp scheme that is used by the existing arm32 code.
Using SIGILLs to detect features is fine but what about (possibly stupid
question) using getauxval() for AArch64 in VG_(machine_get_hwcaps)? It's
called once from valgrind_main() on startup. I notice for x86 (VGA_x86)
cpuid is used.
> Given that your tests/arm64_features.c lists 40+ capability subsets
> for 8.1, I suggest you only add VEX_HWCAPS_ARM64_* for the ones you
> want to implement. Also, it might be worth considering whether it's
> possible to merge some of those classes -- maybe some of the features
> are implemented in groups?
Good idea. The features could be grouped by ISA version, e.g.
v8.1 has atomics and asimdrdm (SQRDMLAH/SQRDMLSH)
v8.2 has dcpop, SHA and dot product instructions
> All of this should be done in a new patch.
I've created https://bugs.kde.org/show_bug.cgi?id=414268
> This patch (v8.1-a LSE instructions) looks ready to go.
Thanks! What's the next step to get it merged into the repo?
Can we merge https://bugs.kde.org/show_bug.cgi?id=413547 as well?
> Finally .. I'm unclear what the top level set of capabilities you're
> aiming to implement, is. Could you please open a meta-bug which simply
> links to all the other bugs involved? So as to have a single
> "starting point".
I've created https://bugs.kde.org/show_bug.cgi?id=414270 for v8.1
I'll create another meta-bug for v8.2 work when I start on that.
--
You are receiving this mail because:
You are watching all bug changes.
