On 11 November 2015 at 00:45, Savolainen, Petri (Nokia - FI/Espoo) <
petri.savolainen(a)nokia.com> wrote:
>
>
> > -----Original Message-----
> > From: lng-odp [mailto:lng-odp-bounces@lists.linaro.org] On Behalf Of
> > EXT Nicolas Morey-Chaisemartin
> > Sent: Tuesday, November 10, 2015 5:13 PM
> > To: Zoltan Kiss; linaro-toolchain(a)lists.linaro.org
> > Cc: lng-odp
> > Subject: Re: [lng-odp] Runtime inlining
> >
> > As I said in the call last week, the problem is wider than that.
> >
> > ODP specifies a lot of types but not their sizes, a lot of
> > enums/defines (things like ODP_PKTIO_INVALID) but not their value
> > either.
> > For our port a lot of those values were changed for
> > performance/implementation reason. So I'm not even compatible between
> > one version of our ODP port and another one.
> >
> > The only way I can see to solve this is for ODP to fix the size of all
> > these types.
> > Default/Invalid values are not that easy, as a pointer would have a
> > completely different behaviour from structs/bitfields
> >
> > Nicolas
> >
>
> Type sizes do not need to be fixed in general, but only when an
> application is build for binary compatibility (the use case we are talking
> here). Binary compatibility and thus the fixed type sizes are defined per
> ISA.
>
> We can e.g. define a configure target (for our reference implementation ==
> linux-generic) "--binary-compatible=armv8.x" or
> "--binary-compatible=x86_64". When you build your application with that
> option, "platform dependent" types and constants would be fixed to
> pre-defined values specified in (new) ODP API arch files.
>
> So instead of building against
> odp/platform/linux-generic/include/odp/plat/queue_types.h ...
>
> typedef ODP_HANDLE_T(odp_queue_t);
> #define ODP_QUEUE_INVALID _odp_cast_scalar(odp_queue_t, 0)
> #define ODP_QUEUE_NAME_LEN 32
>
>
> ... you'd build against odp/arch/armv8.x/include/odp/queue_types.h ...
>
With the introduction of odp/arch at the top level I think we should also
move platform/linux-generic/arch to the same location
> typedef uintptr_t odp_queue_t;
> #define ODP_QUEUE_INVALID ((uintptr_t)0)
> #define ODP_QUEUE_NAME_LEN 64
>
>
> ... or odp/arch/x86_64/include/odp/queue_types.h
>
> typedef uint64_t odp_queue_t;
> #define ODP_QUEUE_INVALID ((uint64_t)0xffffffffffffffff)
> #define ODP_QUEUE_NAME_LEN 32
>
>
> For highest performance on a fixed target platform, you'd still build
> against the platform directly
>
> odp/platform/<soc_vendor_xyz>/include/odp/plat/queue_types.h
>
> typedef xyz_queue_desc_t * odp_queue_t;
> #define ODP_QUEUE_INVALID ((xyz_queue_desc_t *)0xdeadbeef)
> #define ODP_QUEUE_NAME_LEN 20
>
>
> -Petri
>
>
>
>
> _______________________________________________
> lng-odp mailing list
> lng-odp(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/lng-odp
>
--
Mike Holmes
Technical Manager - Linaro Networking Group
Linaro.org <http://www.linaro.org/> *│ *Open source software for ARM SoCs
Holiday [2/10]
Juno crash analysis [2/10]
* Spent some time fiddling with kexec on AArch64
* Worked in one very specific case
* Another patch series is (apparently) coming, will look out for it
and try again
SPEC-on-Android [2/10]
* Supporting Qian on getting this working
* Wrote a readme for the repository, fixed a Makefile bug that Qian's
cross-compiler happened to tickle
Jenkins benchmarking job - TCWG-348 [1/10]
* Tested, tidied up pbl hacks to generate JSON
* Tested my pbl with Jenkins prototype jobs
* A few minor bug fixes/enhancements for pbl
LAVA jobs for uinstance - TCWG-432 [1/10]
* Reworked jobs to support uinstance, maintaining backward
compatibility as far as possible
* Started adding support to submit results to bundle stream
Misc [2/10]
* Debian FS ready to submit
* Usual meetings/mail/etc background
=Plan=
Look at doing pbl hacks properly in Fathi's in-development refactored p-b-l
Pull together Jenkins/LAVA/pbl, ready to test when uinstance is available
Write up noise control report
(If time, if patches land) have another go at crashdump
== Progress ==
o Linaro GCC (4/10)
* Delivered GCC 4.9 2015.10 snapshot
* More backports forGCC 5 2015.11
* Many instabilities on Hetzner this week
o Upstream work (2/10)
* Sanitizing gfortran testsuite
o Release tools (2/10)
* Added RCs and binaries support to our snapshot.linaro.org
publishing job
o Misc (2/10)
* Various meetings
* Some support
== Plan ==
o Track missing backports dependencies
o Continue ongoing tasks.
== This week ==
* TCWG-369 - Exploit wide add operations when appropriate for Aarch64 (4/10)
- Determined that vectorizer is failing for all targets that have
widening adds with
V8HI to V4SI support (aarch64, ia64, powerPC).
- Modified test cases to indicate expected failure with wide add
V8HI to V4SI support
- Patch sent upstream for approval
* Bugzilla 68223 - arm_[su]min_cmp pattern fails
- Resolved by reverting patch for tcwg-146 as pattern fail in some
corner cases. (3/10)
- Reverted patch checked in upstream
* Misc (1/10)
- Conference calls
* Illness, November 2nd (2/10)
== Next week ==
- TCWG-317 - Resolve lto big endian failures
== Progress ==
- Leave (2/10)
- Widening pass (TCWG-547) - 5/10
* Made the latest changes requested in the review
* Fixed bootstrap and bootstrap mis-compare for ppc64-linux-gnu
* Making uninitialized variable as anonymous ssa (as asked in review)
results in few ICEs.
* Posted updated patch for feedback
- Misc (3/10)
* started looking into LTO status
* Looked at LuaJIT for arm
* gcc/bug list
== Plan ==
* continue with widening pass based on feedback
* Look at implementing LuaJIT for aarch64
* LTO
== This week ==
* TCWG-72 (6/10)
- 5 iterations since the original patch. Changes include:
a) Integration into widening_mul patch
b) Rewriting the divmod transform so DIVMOD() is placed before the topmost
div/mod stmt
c) Removed check for widening mode and optab handler check in expand_DIVMOD
d) Fixed ICE when constant is one of the operands to div/mod stmt.
e) Fixed mis-compilation with a test-case when operands matched but in
opposite order.
f) Formatting nits and fixed test-cases.
- Richard suggested no need to check for post-domination conditions.
- Not sure on what condition to gate the transform.
Checking for availability of divmod/div/mod is not sufficient because arm
defines optab handler for mod which only matches r0 % n where n is
constant and power of 2
for other cases it's expanded via divmod libcall thru expand_divmod.
We would rather need
to check if the template for mod/div gets matched than just to check
if optab handler exists.
AFAIK this cannot be done during tree-ssa passes.
I can think of two approaches:
a) Do the transform to DIVMOD representation unconditionally in
widening_mul pass.
And then in expand_DIVMOD check if the template for mod can be matched.
If it does match then undo the transform from DIVMOD to original
representation and expand.
I am not sure how feasible it is to undo the transform at expansion
time, and start expanding the modified cfg.
b) Define a new target hook combine_divmod.
Default implementation could check for optab handler for div/mod/divmod.
and I could override it for arm-backend to additionally check if the
second operand is a constant and power of 2 and fail for this case
(since we want this to be expanded from modsi3 pattern).
Not sure if this is a good idea, I am replicating the information from
the modsi3 pattern.
If the pattern changes, the hook would also need to be changed.
* Convert ASM_FORMAT_PRIVATE_NAME to hook (2/10)
* TCWG-319 (1/10)
- Bencharmking for patch in progress
* Misc (1/10)
- Meetings
- Sync with Kugan
== Next Week ==
- Continue with TCWG-72
- Complete the patch with build, test and config-builds for
ASM_FROMAT_PRIVATE_NAME and submit upstream
- Continue benchmarking TCWG-319, TCWG-310
== Progress ==
* Buildbots (5/10)
- Some broken bots, bisecting, etc
- Helping a MIPS patch pass on ARM bot
* Maintenance (2/10)
- SciMark2 seems not to be unstable or slow any more in ARM64
- Some more investigations on Loop Load Elimination
- Profiling bigfib on APM and HiKey
* Background (3/10)
- Code review, meetings, discussions, general support, etc.
- Some FOSDEM fiddling
- Some power issues
== Progress ==
* Validation
- moved list of unstable tests to a separate repo, to make
maintenance easier (TCWG-425)
- Jenkins jobs maintenance & cleanup
- a few ABE reporting patches
- comparison of results between old & new lab
* GCC
- trunk monitoring, reported a few new failures.
- Send patch to fix vqtb[lx][34] intrinsics on aarch64_be
* Binutils
- Added a Jenkins job to build+check binutils on
a variety of configurations:
https://ci.linaro.org/view/tcwg-ci/job/tcwg-binutils/
- sent a small patch to fix a bug in the recent STM32L4XX erratum patch
== Next ==
* Validation:
- work on the switch to the new lab, once dev-01 is back online
- more tuning to avoid deadlocks
- re-measure build time on dev-01, to better tune other build jobs
* Two half day off. [2/10]
# Progress #
* TCWG-332, fails in gdb.threads/multiple-step-overs.exp. [1/10]
Testing the simpler approach suggested during the review.
* TCWG-387, done. [1/10] GDB patches are pushed in.
* TCWG-422, GNU vector extension support in ARM GDB. [2/10]
Patches are done, and being tested.
* TCWG-423, GNU vector extension support in AArch64 GDB. [2/10]
Writing patches. Find more issues for AArch64 that GDB doesn't
fully understand the AArch64 calling convention. Need more work here.
* Review ARM GDBserver software single step patch. [1/10]
* Misc, meeting, email, [1/10]
# Plan #
* Off on Wed afternoon.
* TCWG-422, post patches
* TCWG-423, continue.
--
Yao
The Linaro Toolchain Working Group is pleased to announce the availability
of the Linaro Stable Binary Toolchain GCC 5.2-2015.11-rc1
Release-Candidate Archives.
http://snapshots.linaro.org/components/toolchain/binaries/5.2-2015.11-rc1/http://snapshots.linaro.org/components/toolchain/gcc-linaro/5.2-2015.11-rc1/
These archives provide cross-toolchain executables (compiler, debugger,
linker, etc.) and shared libraries (libstdc++, libc, etc.) that target ARM
or Aarch64 GNU/Linux and bare-metal environments. The cross-toolchain
binaries execute on a Linux or MS Windows (under mingw32) host
operating-system.
Please evaluate this release-candidate for correctness. Linaro will
shortly spin the Linaro GCC 5.2-2015.11 release if this release-candidate
passes stakeholder validation.
For bugs related to this release-candidate please email
linaro-toolchain(a)lists.linaro.org or file a bug at
https://bugs.linaro.org/enter_bug.cgi?product=Linux%20Binary%20toolchain
NEWS
* GCC 5.2 2015.11-rc1
The Linaro GCC 5.2 2015.11-rc1 binary toolchain release-candidate is
built from the Linaro GCC-5.2-2015.11 release-candidate source archive.
The Linaro GCC-5.2-2015.11 release source archive is derived from the same
sources as the Linaro GCC-5.2-2015.10 snapshot source archive.
--
Ryan S. Arnold
Linaro Toolchain Working Group - Engineering Manager
www.linaro.org
Dear List,
I'm new to this list and have some questions.
Looking at the created code of GCC on ARMv8, we noticed some areas where there is room for performance improvements.
I assume that these items might already be noticed by you guys.
For example:
1) We noticed that when writing typical DGEMM like code, GCC includes unnecessary DUP instruction
2) GCC seems unwilling to use LDP loads
3) For optimal FPU performance on some A57 its needed to interleave instruction working on ODD and EVEN registers
GCC seem not properly support this. Here sometimes 100% performance increase could be reached by different instruction interleaving.
4) Some work loops highly benefit of interleaving of FPU instructinons and loads.
GCC seems to likes to re-arrange the code so that most or all loads are put on top of the loop.
This can reduce the performance of a well written workloop significantly.
I have no patches to fix this.
But I can produce C- code and ASM output which will show these performance issues.
Please tell me what the next recommended step will be now.
Are all these items known already, or shall I provide code examples to further explain them?
Kind regards
Gunnar von Boehn
== Progress ==
* Validation
- comparing results and build times between the 2 labs
- tuning jobs scheduling to avoid deadlocks
* GCC trunk monitoring
- lots of validation results to check after 1 week of holidays :-)
- a few regressions/new failures/wrong tests reported
* Backports
- a few reviews
== Next ==
* Infrastructure/Validation
* GCC dev: try to fix vqtbl intrinsics for aarch64_be before e/o stage1
The Linaro Toolchain Working Group (TCWG) is pleased to announce the
2015.10 snapshot of the Linaro GCC 4.9 source package.
This snapshot[1] is based on FSF GCC 4.9.4-pre+svn229467 and includes
performance improvements and bug fixes backported from mainline GCC.
This snapshot contents will be part of the 2015.11 stable [1]
quarterly release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/4.9-2015.10/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 4.9.4-pre+svn229467
* Backport of [Bugfix] PR tree-optimization/65735
* Backport of [Bugfix] PR tree-optimization/65177
* Backport of [Bugfix] PR tree-optimization/65048
Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC
channels to stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Interested in commercial support? inquire at "Linaro support":
mailto:support@linaro.org
[1]. Stable source package releases are defined as releases where the
full Linaro Toolchain validation plan is executed.
[2]. Source package snapshots are defined when the compiler is only
put through unit-testing and full validation is not performed.
== Progress ==
o Linaro GCC (9/10)
* Backports and reviews for our GCC 5 2015.11 snapshot
* FSF branch merge and needed backports for our GCC 4.9 2015.10 snapshot
o Misc (1/10)
* Various meetings
== Plan ==
o Complete 4.9 snapshot
Noise control experiments - TCWG-358 [3/10]
* Some analysis of data to date
Debian filesystem - TCWG-360 [3/10]
* Got stuck on LAVA interactions
* Now booting-to-LAVA-usability, needs some cleanup and testing with
real benchmark runs
Benchmarking-via-Jenkins - TCWG-348 [1/10]
* Picked back up on understanding that LAVA uinstance is a-coming
* Hacked pbl.py (post-build-lava) to generate suitable JSON
** As a bonus, this can work as a CLI job-submission tool
=Plan=
Holiday Friday (pending approval)
Set up crashdumping on my Juno, try to learn why it crashes
Finish Debian filesystem
Get Jenkins generating and submitting jobs suitable for uinstance
Write up noise control report (probably will get bumped to next week)
== This week ==
* TCWG-317 - Exploit wide add operations when appropriate for Aarch32 (3/10)
- Could not reproduce test failure in qemu
- Waiting on feedback from Maxim who is running patch on Linaro
validation
* TCWG-369 - Exploit wide add operations when appropriate for Aarch64 (4/10)
- Debugging tree vectorizer to determine why loops with no wide add
operations are no longer being vectorized
* TCWG 146 - Debugging regression on arm big endian with Linaro 5 branch
(2/10)
* Misc (1/10)
- Conference calls
== Next week ==
- TCWG-317 - Resolve lto big endian failures
- TCWG-369 - Identify why loops are not being vectorized
- TCWG-146 - Resolve big endian failures
== This Week ==
* TCWG-72 / PR43721 (8/10)
- Completed writing expand_DIVMOD() and submitted patch upstream
- Reworked patch according to Richard Biener's comments.
(http://people.linaro.org/~prathamesh.kulkarni/pr43721-patch-v2.diff)
- Wrote test-cases.
* TCWG-319 (1/10)
- Benchmark run without patch complete for "int" benchmarks on a53, a57
- Benchmark run with patch in progress for "int" benchmarks on a53, a57
* Misc (1/10)
- Meetings
== Next Week ==
- Continue with TCWG-72, TCWG-310li, TCWG-319 benchmarking
# Progress #
* TCWG-332, [1/10], patch is posted for review.
* TCWG-187, [1/10], looks like a kernel (~3.4) bug on setting VFP
registers through ptrace. Fails go away after I upgrade the kernel.
* TCWG-387, [2/10], binutils patch is committed, while GDB
patches are being reviewed.
* TCWG-422, [3/10], Read AAPCS and gcc source code to understand the
calling convention. On going.
* FSF patch review, [2/10]
** Review patch set "all-stop on top of non-stop for remote".
** Review ARM fast tracepoint patches.
** Reopen PR 15564, as the fail isn't fixed.
* Misc, meeting, [1/10]
# Plan #
* TCWG-422
* Support ST on using AArch64 multi-arch GDB if needed.
* Review ARM GDBserver software single step patch.
--
Yao
== This week ==
* TCWG-317 - Exploit wide add operations when appropriate for Aarch32 (5/10)
- Continued to debug big endian/lto failure of four torture tests
- Differences in lto vs. non-lto executables showed no significant
differences
* TCWG-369 - Exploit wide add operations when appropriate for Aarch64 (4/10)
- Resolved three of six test suite failures
* Misc (1/10)
- Conference calls
== Next week ==
- TCWG-317 - Resolve lto big endian failures by debugging test cases
with qemu
- TCWG-369 - Resolve remaining test suite failures
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
Hello all,
When upgrading meta-linaro/meta-linaro-toolchain from daisy to fido, we faced drastic performance downgrade (-34.06%) on linux ipv4 forwarding. The board is ls1021atwr (ARM Cortex-A7 MPCore compliant with ARMv7-A architecture).
We did some investigation, and suspected that it is caused by the toolchain upgrade. Did someone meet similar issue?
The detailed toolchain info:
https://git.linaro.org/openembedded/meta-linaro.git/shortlog/refs/heads/fido
gcc-linaro-4.9.3-2015.03, glibc-linaro-2.20-2014.11, binutils-linaro-2.25-2015.01
https://git.linaro.org/openembedded/meta-linaro.git/shortlog/refs/heads/dai…
gcc-linaro-4.8.3-2014.04, eglibc-linaro-2.19-r2014.04, binutils-linaro-2.24-r2014.03
thanks.
-Ting
o Week 42 off (10/10)
== Progress ==
o Linaro GCC (9/10)
* Completed backports and reviews
* Delivered GCC 5 2015.10 snapshot
* Completed TCWG 389 (deploy snapshot job)
o Misc (1/10)
* Various meetings
== Plan ==
o Back to work
Mustang benchmarking bringup - (no ticket) [2/10]
Controlled Debian build - TCWG-360 [1/10]
* Constructed filesystem, works OK as chroot
* Next step is to boot it
Investigate Workload Automation framework - TCWG-361 [1/10]
* Seems to basically work
* SPEC support dubious
Misc
* LAVA uinstance background (TCWG-396, < 1/10)
* Noise control experiments (TCWG-358, < 1/10)
* ARM management duties [2/10]
== Progress ==
* Maintenance (5/10)
- Investigating some LivermoreLoops that don't vectorise
- Reducing cases to single specific causes
* Background (5/10)
- Code review, meetings, discussions, general support, etc.
- More code of conduct stuff, license change to Apache 2
- Following up on sanitizers VMA discussion
