o 1 day off (2/10)
== Progress ==
o Linaro GCC/Validation (4/10)
* ABE and validation jobs reviews
* Binary tarballs size reduction:
- more tests and investigation (mingw in particular)
- investigating compressed debug sections
* BZ #2575:
- Bugfix proposed upstream by Jakub
- Validate it
o Misc (4/10)
* Various meetings and discussions.
* office network issues
== Plan ==
o Branch merge and snaphsot release
o release binaries size reduction
== This Week ==
* PR35691 (2/10)
- Fix committed to trunk for case when LOGICAL_OP_NON_SHORT_CIRCUIT is true.
- Fixed PR78256, caused by the commit.
* PR78335 (2/10)
- Created patch
* PR35503 (1/10)
- Rebased and committed to trunk after validation
* PR78139 (1/10)
- Caused due to r241915 which fixes PR35691
- Perhaps this is a latent issue in uninit pass triggered by the
commit, but I need to investigate
further to confirm that.
* ipa-split pass (2/10)
- Working on patch to pass variables defined in header block to split
function via arguments.
* Misc (2/10)
- GCC Bugzilla list
- Meetings
== Next Week ==
- Benchmark LTO for section-anchors
- GCC bugs: PR78154, PR78139, PR78335
- ipa-split pass
TCWG-901 Investigate lld as a system linker
- Installed lld as the system linker on my Chromebook and attempted to
build and run things to see what breaks
- Only one unknown concrete problem found so far, thunks to undefined
symbols with PLT entries don't work. This seems to be common in python
C extensions that are dlopened from python, and call back to the
interpreter.
-- I have a downstream fix (TCWG-919), with this fixed the test-suite
can run with lld as the linker through the pip install (SQLAlchemy has
C extensions).
- As thought previously, clang is too big to link without thunks.
- Attempted to make a simple add thunks to all branches to see if I
could get clang to link. Sadly this won't work as lld only permits one
thunk per symbol and this might be out of range of the caller as well.
- Some thoughts and experiments on how much of llvm, compiler-rt,
clang and libc++ can be linked with lld. I'm currently thinking of
altering my lld driver to automatically switch to ld.bfd after a
relocation out of range link error. I want to try and get a lld linked
clang + compiler-rt +libc++ system running.
TCWG-683 lld support for branches to unresolved weak references
- Now upstream
Also:
- A lot of rebasing of downstream patches as some refactoring is going
on to make lld more flexible.
- Some inconclusive investigation into weak reference behaviour in GNU
ld. The ARM and AArch64 ld.bfd linkers will put a dynamic relocation
on a got slot generated by for an unresolved weak reference. The x86
linkers do not, they statically resolve the got slot to 0.
- Some inconclusive investigations into trying to work out what
packages to build to test lld. With the exception of very large
programs ld seems to successfully complete the link for all programs.
Whether it has done so correctly or not is another matter.
-- Currently thinking about whether I can build a BSD make world on a
raspberry pi.
Plans for next week:
- Bring TCWG-901 to a close and work out what to work on next.
== Progress ==
* Rewrite llvm-projs in Python [TCWG-833] [2/10]
- Investigated clitest for testing the scripts
- It seems to be a bit unwieldy for our purposes, so in the end it's
probably a better idea to abuse Python's unittest module even for higher
level tests (they'll be in a different directory though)
* [ARM GlobalISel] Select add instructions [TCWG-925] [6/10]
- Committed a patch upstream with all the plumbing necessary for enabling
GlobalISel for ARM
- Working towards selecting an add instruction on i32 types - currently
have some naive support for lowering arguments and selecting return and
copy instructions
* Misc [2/10]
- Meetings, mailing lists, buildbot monitoring
- Python trainings
== Plan ==
* [ARM GlobalISel] Select add instructions [TCWG-925]
- Brush it up and send it upstream
* Rewrite llvm-projs in Python [TCWG-833]
- Start a discussion on the interface / repo layout etc
# Progress #
* TCWG-547. Change software_single_step interface to return a vector of address
Patches are pushed in. Done. [1/10]
* TCWG-923, Use regcache instead of frame in software_single_step. [3/10]
Patches are finished. Tests are needed.
* TCWG-333, Fix gdb.base/func-ptrs.exp fails in thumb mode. [4/10]
Clean up val_print, remove one redundant parameter. Patches are
committed.
Deep diving in the gdb value objects. Much cleanup work should be
done first. Ongoing.
* More patches review, [2/10]
** C++ 11 patches, and learn C++ 11 in parallel,
** Review arm tracepoint patches. Insist that they (Ericsson) have to
fix underlining bugs (intermittent fails) before getting patches
in,
** Discuss on MIPS reconfigurable FP registers. Proposed two ways in
public gdb mail list, MIPS people think the first one is a little
better
** Hold Intel's fortran patch until a bug we found in gfortran is
confirmed.
# Plan #
* TCWG-923,
* Training from Tue to Friday.
--
Yao Qi
o 1 day off (2/10)
== Progress ==
o Linaro GCC/Validation (3/10)
* ABE and validation jobs reviews
* Binary tarballs size reduction:
- testing patch
* BZ #2575:
- Investigate and open bug upstream (PR78201)
- Testing current fix and investigating bugzilla feedbacks
o Misc (3/10)
* Various meetings and discussions.
== Plan ==
o Continue on tarball size reduction and BZ
== This Week ==
* ipa mod/ref analysis (2/10)
- Prototype patch now detects modifications to reference parameters
- Working on mod/ref analysis of global variables.
* PR35691 (2/10)
- Patch iterations based on upstream review
* PR35503 (2/10)
- Patch approved by Jason
- Building kernel with patch resulted in two warnings.
* Public Holidays (4/10)
== Next Week ==
- IPA mod/ref prototype
- Bugs
-- Activity --
[TCWG-683] Branch to undefined weak on aarch64 and arm
Fix in upstream review, looks pretty close to being accepted.
[TCWG-828] TLS support for static linking
In upstream review but no comments as yet
[TCWG-829] IFunc support
In upstream review, but will probably need to be rewritten after some
upstream refactoring has finished
[TCWG-911] eglibc requires a SHT_ARM_ATTRIBUTES section for dlopen to work
I have a quick hack to work round this on my Chromebook but a full fix
will take some time as lld doesn't understand build attributes right
now.
[TCWG-901] Investigate lld as a system linker
With downstream fixes, using lld as the system linker on a Chromebook I can :
- Build llvm, lld and run the regression tests successfully
- Use lld as the linker in the lnt tests successfully
- Using lld to build the shared objects used by lnt's python C
extensions was less successful. I have some interesting debugging to
do.
-- Plan --
Debug the python extension problems
Respond to upstream review comments
More use of lld as system linker
== Progress ==
* [ARM] Investigate switching from itineraries to schedule models
[TCWG-824] [4/10]
- Looked at the sched model as well as the old instruction itinerary
interfaces
- There aren't many tests that are specifically testing the scheduler,
but lots of tests break if you make enough changes to it (it's unclear
which of these are breaking intentionally and which are just poorly written)
- First step is probably to try and complete the sched model (TCWG-543),
then hunt down any differences between what we get using itineraries and
what we get with the new model
* Rewrite llvm-projs in Python [TCWG-833] [3/10]
- Reorganized the repo so we can have a separate tests directory
- Added support for parsing command line options
- Almost ready for review
* Misc [2/10]
- Catching up after vacation
- LLVM GitHub move survey
== Plan ==
* Wrap up TCWG-833
* Migrate scripts to Python 3 (TCWG-896)
* Maybe start TCWG-543 as the first step in TCWG-824
