From 0e8bb47d7ad1da80ee1d07e7f788ea018aeceb6c Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 12 Jan 2021 17:47:11 +0000 Subject: [PATCH] --- openpower/sv/svp64/appendix.mdwn | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/openpower/sv/svp64/appendix.mdwn b/openpower/sv/svp64/appendix.mdwn index cf583c483..a0d42385a 100644 --- a/openpower/sv/svp64/appendix.mdwn +++ b/openpower/sv/svp64/appendix.mdwn @@ -1,6 +1,7 @@ # Appendix * +* This is the appendix to [[sv/svp64]], providing explanations of modes etc. leaving the main svp64 page's primary purpose as outlining the instruction format. @@ -298,6 +299,20 @@ the access pattern needs to be understandable in relation to v3.0B / v3.1B numbering, with a clear linear relationship and mapping existing when SV is applied. +## Analysis for compilers + +gcc and llvm automatically manage CRs: they are not explicitly accessible even at the assembly level (asm statement). This causes something of an issue even just for basic testing. A solution then is to leverage the following: + +* scalar instructions produce scalar CRs. +* gcc and llvm scalar instructions produce scalar CRs. +* vector instructions produce vector CRs +* therefore with the exception of branches there should be a match which does not require heavy modification of gcc + +The basic principle being to ensure that Vector attribute tags propagate through to the CRs. For this to worrk all gcc and llvm code must act as if the numbering of CRs is kept entirely looking scalar despite the fact that it is actually vector. + +Thus the compiler when referring to CR0 still generates code that it thinks is scalar and thinks a scalar computation created CR0 but the same code serves double-duty and thus does not need drastic rewrites or modification. + + ## CR EXTRA mapping table and algorithm Numbering relationships for CR fields are already complex due to being -- 2.30.2