== Progress ==
* Out of office on Friday (bank holiday)
* [GlobalISel] Refactor CallLowering [LLVM-568]
- Patches upstream
* [ARM GlobalISel] Add support for integers > 32 bits wide [LLVM-310]
- Started looking into call lowering for 64-bit types
* LLVM SPEC2k6 Performance Analysis [LLVM-134]
- Trying to reproduce results from Connect, hit a little snag with Jenkins
== Plan ==
* Continue with these
[LLVM-542] Build Zephyr with clang
- Spent quite a bit of time working out why a Clang built zephy hello
world wouldn't boot, tracked down to a missing clobber list in an
inline assembly block
- Wrote some scripts to collect code size information on the samples.
Some initial figures on mostly cortex-m3 put llvm -Oz trunk about 2%
larger than arm-none-eabi-gcc (9.1.1) -Os with frame pointers
disabled. The samples are making very little use of the library
(newlib built with arm-none-eabi-gcc).
- Working out which samples will build with cortex-m0.
- Investigated latest version of bloaty mc bloat face a code size tool
from Google. Has some interesting features including an inline
detection feature that can map a portion of a function's code size to
inlined functions.
Misc:
LLD reviews and mailing list comments.
Planned Absences:
Likely to take some holiday around 13th July
Week ending 23 June is very short.
* Patch review
- target/ppc vsr cleanup
- target/tricore translator loop conversion
- target/arm vfp decodetree cleanup
- cortex-strings strrchr fix
- continuing on the plugin api
* Xilinx meeting
* Fix qemu assert for clyon
- Found two other bugs in the process.
* Debugging my own USHR/SSHR patch vs aa32.
r~
Progress: (very short week, 2 days)
* VIRT-65 [QEMU upstream maintainership]
+ found and sent patches for a handful of minor M-profile bugs
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ the final patches for this have now gone upstream and I have
marked the JIRA issue as resolved. There may still be minor
bug fixes but we can handle those under the usual 'upstream
maintainership' JIRA
thanks
-- PMM
Hello folks,
I got a few people asking me to do this in the last Connect, so I've
proposed a beginner session that explores gcc under the hood. The
tentative plan I have for the talk is:
1. A high level view of how the source code is laid out
2. Front end, middle end, backend. This includes a high level
introduction of GIMPLE and machine descriptions
3. A walkthrough of one or two simple programs and usage of diagnostic
flags like -fdump-*
Additional suggestions are most welcome. Also, I was thinking maybe
it would be good to have a llvm under the hood talk along similar
lines. Thoughts?
Siddhesh
[LLVM-571] Build GNU rmprofile toolchain with Linaro scripts (abe)
The existing build-system was only set up to build the A-profile bare
metal toolchain. Managed to find right combination of flags and
modifications to get a toolchain that zephyr can use.
[LLVM-158] Buildbot maintenance
An interesting failure introduced in LLD, but causing segfaults in
2-stage build, now fixed.
[LLVM-542] Zephyr code size investigation
- Rebased modifications to Zephyr
- Wrote script to build all the examples with GCC and Clang
- Fixed problems with modifications found by building all the examples
- Clang built helloworld no longer booting, need to investigate
- Found some areas for more investigation:
-- llvm-objcopy missing --gap-fill (used by one of the sample programs)
-- lld missing --print-memory-usage, while I'm using gcc for the main
link, zephyr build system seems to be feature testing using clang bare
metal default linker (lld)
-- clang always generates .note.GNU.stack, gcc embedded does not,
leading to lots of orphan section warnings. Probably best solved by
linker script modification.
Progress:
* VIRT-65 [QEMU upstream maintainership]
+ some work on getting Sphinx to generate manpages, with a conversion
of the qemu-ga manpage from texinfo as the demonstration case
+ set up to run pre-merge tests on our packet.net qemu-test machine
rather than the gcc compile farm one (as the latter is running an
ancient ubuntu whose python is now too old to build QEMU with)
+ sent some follow-on cleanup patches now that VFP decodetree is in master
* VIRT-268 [QEMU support for dual-core Cortex-M Musca board]
+ sent out patches which correctly make the Cortex-M33 (and the -M4)
implement single-precision-only floating point, so the double-precision
instructions UNDEF as they should
+ once those and the other on-list patches have made their way through
code review and into master this epic will be complete
thanks
-- PMM
