== Progress ==
* Out of office on Monday [2/10]
* [ARM GlobalISel] Investigate divmod [TCWG-1086]
- Broke this up into several smaller stories
* [ARM GlobalISel] Support sub and mul [TCWG-1104] [1/10]
- Committed upstream
* [ARM GlobalISel] Support trunc [TCWG-1109] [1/10]
- Committed upstream
* [ARM GlobalISel] Support div [TCWG-1103] [2/10]
- Mostly done, will upstream next week
* [ARM GlobalISel] Fix fallback path [TCWG-1110] [2/10]
- Oliver from ARM has started running csmith with GlobalISel and is
finding several issues
- Fixed one of them and committed upstream
- Will commit another one next week
* Misc [2/10]
- Meetings, mailing lists, code reviews, buildbots
- Minor cleanup in the ARM backend (renamed a subtarget feature to
avoid future misuse)
== Plan ==
* [ARM GlobalISel] Fix fallback path [TCWG-1110]
* [ARM GlobalISel] Support div [TCWG-1103]
* Resume [ARM GlobalISel] Use TableGen for inst selector [TCWG-1037]
3 day week,Monday and Tuesday off
Achievements:
[TCWG-614] Range Thunks
- No review progress, blocked on a request for some refactoring to
unify the address allocation.
- Reworked my downstream patch stack in light of TCWG-1088 below.
- Spent some time refactoring the code to try and make it easier to follow.
[TCWG-1088] Refactoring of address assignment
- Committed first patch reviewed last week
- Sent out first couple of patches, no response from upstream, I'm
hoping this is due to maintainers being on Easter holiday.
Some upstream review on ILP32 patches.
Plans for next week:
- 2 day week, at ACCU2017 conference Wednesday to Friday.
- Respond to any upstream review comments.
- Find some small tasks to do to fit in the remainder of the time.
Planned Absences
- ACCU2017 next week (Wednesday to Friday)
I'm working on my HiKey. I'm trying to enable CRC extension on ARMv8
in the assembler regardless of the way GCC was built, and regardless
of the user's CFLAGS and CXXFLAGS. I'm encountering an assembler
error: "unknown pseudo-op: `.arch_extension'".
According to [1], I can use ".arch_extension" to enable it. According
to [2], ".arch_extension" is available in GCC 4.6 and GAS 2.21. My
version of Linaro provides GCC 4.9.2 and GAS 2.25.90. I can also
duplicate the issue on GCC113 (compiel farm), which provides GCC 4.8
and GAS 2.24.
The test program is below. Trying to compile it results in:
$ g++ test.cxx -c
/tmp/ccVZ6hiq.s: Assembler messages:
/tmp/ccVZ6hiq.s:24: Error: unknown pseudo-op: `.arch_extension'
/tmp/ccVZ6hiq.s:25: Error: selected processor does not support `crc32b w1,w0,w0'
Trying to compile without ".arch_extension" results in:
$ g++ test.cxx -c
/tmp/cci4wu6d.s: Assembler messages:
/tmp/cci4wu6d.s:24: Error: selected processor does not support `crc32b w1,w0,w0'
Its almost as if ".arch_extension" is not being properly recognized or consumed.
Any ideas what might be going wrong here?
**********
The program:
$ cat test.cxx
#include <arm_neon.h>
#define GCC_INLINE_ATTRIB __attribute__((__gnu_inline__,
__always_inline__, __artificial__))
#if defined(__GNUC__) && !defined(__ARM_FEATURE_CRC32)
__inline unsigned int GCC_INLINE_ATTRIB
CRC32B(unsigned int crc, unsigned char v)
{
unsigned int r;
asm (" \n"
".arch_extension crc \n"
"\t" "crc32b %w2, %w1, %w0 \n"
: "=r"(r) : "r"(crc), "r"((unsigned int)v));
return r;
}
#else
// just use the instrinsic
# define CRC32B(a,b) __crc32b(a,b)
#endif
int main(int argc, char* argv[])
{
return CRC32B(argc, argc);
}
**********
Versions...
$ gcc --version
gcc (Ubuntu/Linaro 4.8.4-2ubuntu1~14.04.3) 4.8.4
$ as -v
GNU assembler version 2.24 (aarch64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.24
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
[1] https://sourceware.org/binutils/docs/as/AArch64-Directives.html#AArch64-Dir…
[2] https://gcc.gnu.org/ml/gcc-help/2012-07/msg00180.html
* Child care (2/10)
== Progress ==
o Linaro GCC/Validation (5/10)
* Released GCC 5 and 6 Linaro source sanpshots
* Progressing on release automation
* Preparing GCC 7 preview release:
- found a build issue for mingw toolchains
- proposed a fix upstream, discussion on-going.
o Misc (3/10)
* Various meetings and discussions.
== Plan ==
o Continue release on automation and prepare 2017.05 RC
== Progress ==
* Validation
- kernelci/lava-ci scripts update broke my prototype. We need more
discussion at this point.
- benchmarking scripts, debugging with Jenkins
- reviews
* GCC
- reported a regression on trunk after an LRA fix, now fixed by Vladimir.
- bootstrapping gcc-5 on armv7 (using present continuous because
it's taking so long)
- Linaro bugzilla
* misc (conf-calls, meetings, emails, ....)
== Next ==
* Validation?
* Benchmarking: debug scripts/jenkins/board setup
* Off Monday 17th
[TCWG-614] Range Thunks
- No review progress, blocked on a request for some refactoring to
unify the address allocation.
[TCWG-1088] Refactoring of address assignment
- Found out that linker scripts can break ARM exceptions in the same
way as they can break the thunk insertion
- Made a prototype of unified address allocation that is good enough
for the current interworking range thunks. This passes the existing
test case that I made to show that linker scripts could break the Mips
LA25 thunk placement.
[TCWG-1089] Fixed problem with ARM exceptions and identical code folding
Plans for next week:
On Holiday Tuesday
[TCWG-1088] Polish up patches and send for review.
Planned Absences:
Tuesday 18th April
Wednesday - Friday 27 - 29 April ACCU 2017
# Progress #
* TCWG-1050, GDB 8.0 release. [4/10]
Release branch is not created, but a lot of C++
patches are posted, and massively change the code even when release
is coming.
** Fix PR 19942, patch v2 is OK. Committed.
** Intel btrace python interface. Intel people posted patches to
adjust the interface as I requested. Reviewing them. They look
much better.
* TCWG-1040, Review SVE patches. [4/10]
SVE patches review. Read Alan's patches and various GDB backends,
like mips, xtensa, and ia64. Feel nervous to approve them because we
have no way testing them. Figure out a unit test to related methods,
and it works well if I build GDB with ASAN. This unit test does find
some existing issues, and patches are posted. In order to make the
test more useful, need to C++-fy regcache, not a small piece of work.
* Upstream reviews [2/10]
** Software single-step on arm-non-eabi. Convince the author that his
patch will break GDB's default behavior, and give some thoughts on
fixing it.
** Propose to deprecate ARM FPA in GDB.
So far, I am not clear what is the "right" process to deprecate
features in GDB. (I know how to deprecate ports and commands).
** Some one complains GDB can't unwind from arm64 kernel irq vector,
which is hand written asm. The fix should be using .cfi directives
to annotate them, however, they want GDB to error out if it can't
unwind. I am suggested to ask in linux-arm-kernel(a)lists.infradead.org
about the expected behavior. Will do next week.
# Plan #
* Mon and Tue off.
* Figure out more ways to test code touched by SVE patches. Convert
regcache to class if necessary.
--
Yao Qi
== Progress ==
* Out of office on Friday [2/10]
* [ARM GlobalISel] Add support for soft float targets [TCWG-1039] [2/10]
- Committed G_FPOW and G_FADD upstream
- Most of the other soft float libcalls are just a matter of boilerplate
* [GlobalISel] Investigate divmod [TCWG-1086] [5/10]
- Working on a patch to support G_(S|U)REM in GlobalISel
- Found an inconsistency in DAGISel, sent a patch upstream
* Misc [1/10]
- Mailing lists, meetings
- Buildbot monitoring (did a bisection, reverted a few patches)
== Plan ==
* Out of office on Monday
* Send patch for TCWG-1086
