[ACTIVITY] report week ending 12 Oct

[Peter Maydell]

Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review:
+ Xilinx Versal SoC support
- investigated problem with a "suppress this warning patch" which
gcc 8 didn't like. It turns out that _Pragma() in GCC is a bit
of a disaster area; fortunately we only need to suppress a
warning here for clang, so we can just avoid using _Pragma() with GCC.
(cf GCC bugs 85153, 69558, 82335, 66099, 55578, 69543.
clang is not flawless here either: cf clang bugs 31999, 15129, 35154.
The clang false-positive warning we're working around is bug 39113.)

* VIRT-164 [improve Cortex-M emulation]
- stack-limit emulation patches have now gone into master, so this
epic can be closed out. Some v8M work will continue under
VIRT-268 (notably FP emulation); bugfixing and similar
small work will go under the general VIRT-65 maintainership epic.

* VIRT-215 ["run microvisors", aka support AArch32 Hyp mode]
- working through some of the HCR bits we don't implement, to see
if any of them are the cause of the failures I see with AArch32
hypervisors. (Sadly they don't seem to be.) Sent out patches
implementing HCR.{FB,DC,VI,VF,PTW} and fixing some syndrome
reporting corner cases where AArch32 differs from AArch64.

thanks
-- PMM

[Peter Smith]

[TCWG-1473] Fix -fno-integrated-as and -mbig-endian (Linux Kernel
Build with clang)
- Needed some revision to handle linker emulation. Patch in upstream review
[TCWG-1474] Fix out of range branch (CBZ) when -fimplicit-it (or
-fno-integrated-as) and certain kinds of inline assembly
- Committed upstream.
[TCWG-1424] Code-size investigations with PGO
- Marking functions for size optimisation at the earliest possible
stage improves code-size for little loss in performance. The main
beneficiary is that loops are not unrolled in size optimised functions
and inline thresholds are lower.
- LTO with instrumented profiling still sees large increase in size.
Originally thought my changes weren't working with LTO but I think
that something else is happening.
-- Found out that the profiling information isn't being sent to the
LTO code-generator (although it should be present as IR annotations
from the objects.
-- There is an option to pass the sample profile through to the LTO
code-generator but not an instrumented profile file.
-- It seems like the LTO plugin doesn't use the new pass manager
unless a separate option is passed through to the code-generator.
-- It seems like Thin-LTO is where most of upstream development is
these days and there is a slightly different pass pipeline, and some
interaction with profiling. Worth some more experiments.

First draft made of incorporating YVR18 Jira discussion into
Confluence https://collaborate.linaro.org/display/TCWG/JIRA+Usage+and+Best+Practices