The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2017.09
snapshot of Linaro GCC 6 and 7 source packages.
o The GCC 7 series introduced an ABI change for ARM targets by fixing a bug
(present since GCC 5, see link below) that affects conformance to the procedure
call standard (AAPCS). The bug affects some C++ code where class objects are
passed by value to functions and could result in incorrect or inconsistent code
being generated. If the option -Wpsabi is enabled (on by default) the compiler
will emit a diagnostic note for code that might be affected by this ABI change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728
For an explanation of the changes please see the following website:
https://gcc.gnu.org/gcc-7/changes.html
o Linaro GCC 7 monthly snapshot[1] is based on FSF GCC 7.2+svn252337 and
includes performance improvements and bug fixes backported from mainline GCC.
The contents of this snapshot will be part of the 2017.11 stable[2] quarterly
release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/7.2-2017.09/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 7.2+svn252337
* Backports from mainline:
- Backport of [Bugfix] [AArch32] PR target/77308 surprisingly large
stack usage for sha512 on arm
- Backport of [AArch32] Fix ldrd offsets
- Backport of [AArch32] Remove %? string from some Advanced SIMD patterns
- Backport of [AArch64] Add optimized implementation of mersenne twister
- Backport of [AArch64] Add RDMA support to falkor port
- Backport of [AArch64] Fix big endian float immediate moves
- Backport of [AArch64] Fix missing optimization for CMP+AND
- Backport of [AArch64] Fix pattern guard relaxations that are
allowing more constants than they should
- Backport of [AArch64] Fix ThunderX fp vectorizer cost model
- Backport of [AArch64] Generate MLA when multiply + add vector by scalar
- Backport of [AArch64] Implement ALU_BRANCH fusion
- Backport of [AArch64] Improve aarch64 conditional compare usage
- Backport of [AArch64] Improve thunderx_vect_cost some more
- Backport of [AArch64] Move the check for any_condjump_p from
sched-deps to target macros
- Backport of [AArch64] Only allow 0s unconditionally for floating
point values
- Backport of [AArch64] Optimize float immediate moves-HF/DF/SF mode
- Backport of [AArch64] Optimize float immediate moves-infrastructure
- Backport of [AArch64] Optimize float immediate moves-testsuite
- Backport of [AArch64] Optimize integer immediate moves with partial masks
- Backport of [Tesstuite] Fix dg-require-stack-check
- Backport of [Testsuite] [AArch32] Add -mfloat-abi=hard to arm_neon_ok
- Backport of [Testsuite] [AArch64] Fix dbl_mov_immediate_1.c test
- Backport of [Testsuite] [AArch64] gcc.target/aarch64/ccmp_2.c: New test
- Backport of [Cleanup] [AArch32] PR target/68535 arm.c: 5 * set but not used
- Backport of [Doc] [AArch64] Clean up AArch64 options
o Linaro GCC 6 monthly snapshot[1] is based on FSF GCC 6.4+svn252072 and
includes performance improvements and bug fixes backported from mainline GCC.
This snapshot contents will be part of the next maintenance release.
This snapshot tarball is available on:
http://snapshots.linaro.org/components/toolchain/gcc-linaro/6.4-2017.09/
Interesting changes in this GCC source package snapshot include:
* Updates to GCC 6.4+svn252072
o 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]. Source package snapshots are defined when the compiler is only
put through unit-testing and full validation is not performed.
[2]. Stable source package releases are defined as releases where the
full Linaro Toolchain validation plan is executed.
The Linaro Toolchain Working Group (TCWG) is pleased to announce our first
preview-grade ILP32 binary cross-toolchain.
Linaro is supporting AArch64 community effort to introduce ILP32 ABI for
AArch64 Linux, and TCWG will be providing preview-grade ILP32 binary
cross-toolchains alongside our normal release candidates. These toolchains
will be built using community-supported branches for ILP32 ABI of Linux kernel
and Glibc.
This first delivery is based on Linaro GCC 7.1-2017.08-rc1 sources and
available at:
http://snapshots.linaro.org/components/toolchain/binaries/7.1-2017.08-rc1/a…
Contact Linaro
===============
File bugs at http://bugs.linaro.org
For Linaro member support see http://support.linaro.org
For Linaro community support email linaro-toolchain(a)lists.linaro.org
== Progress ==
* Infrastructure:
- patch reviews
* Benchmarking:
- more experiments to reduce noise.
- board reboot + several iterations + use of only 1 core seems to
give manageable results, at the expense of execution time
- old 'deprecated IT blocks' patch benchmarked again with this setup, seems ok
* GCC upstream validation:
- further reduced noise ("random" pass/failures)
- reported a few regressions, looking at improving some testcases
related to branch-cost on arm
* binutils/gdb upstream validation:
- gdbserver build broken on trusty, sent an email to Yao
* GCC
- investigating portability of ubsan to bare-metal targets
* misc (conf-calls, meetings, emails, ....)
== Next ==
* Benchmarking
* GCC upstream validation
* GCC/ubsan
== Progress ==
o Linaro GCC/Validation
* Working on release process
* Reviewed infra patches
* Still some patches pending on upstream reviews
o LLVM
* Familiarizing with LLVM environment
o Misc
* Various meetings and discussions.
* Booked everything for SFO17
== Plan ==
o Backports for 2017.09 snapshot
* 3 days off
== Progress ==
o Linaro GCC/Validation
* Investigating upstream bugzilla PR81863
* Other patches are still pending on upstream reviews
* Working on release process
o Misc
* Various meetings and discussions.
== Plan ==
o PR81863, ...
== This Week ==
* Type promotion (6/10)
- Benchmarking on ARM and AArch64
- Experimenting with pass order to reduce redundancies
- Preparing the patch to send upstream
* PR78809 (2/10)
- Prototype patch done
- Working through testsuite fallout
* PR78736 (1/10)
- Iteration on upstream feedback. Waiting for approval from Fortran
maintainers for
libgfortran changes
* Misc (1/10)
- Submitted https://review.linaro.org/#/c/21111/
- Meetings
== This Week ==
- Submit patch fo type promotion upstream.
- GNU Cauldron 2017
Status of two weeks.
* Bank holiday on Monday and I am off on Tue and Wed. [6/20]
# Progress #
* TCWG-1159, New design of GDB/GDBserver target description. [4/20]
Post my target description v4 patches. They should be ready to
check in, however, I am sidetracked by GNU Cauldron presentation.
* Cauldron presentation. [5/20]
Write the presentation for my target description work above. Ongoing.
latex+beamer+tikz is quite powerful to make presentation.
* My Linaro Connect SFO17 presentation is accepted.
Need to write it in google doc later.
* Review Alan H.'s patches. [2/20]
* Misc [3/20]
# Plan #
* Finish my Cauldron presentation,
* Commit my target description v4 patches, if time allows,
* Off on Wed, and fly to Prague. Back to office on 14th Sep.
--
Yao Qi
Hi,
On 26 August 2017 at 18:10, Pinski, Andrew <Andrew.Pinski(a)cavium.com> wrote:
>> However there might be pushback from upstream maintainers as this makes the structure bigger
>> by adding a field. This could have implications for memory usage of the compiler.
>
> I looked into the structure, adding this field is not going to make the structure bigger for either ILP32 or LP64 targets. If you want, you use bit-fields; there is one bool already there which means you can fit 8 bits in the same area as currently taken up by that one.
Yes. I should have checked the mem_attrs structure. This does have at
least a byte left unlike some other tightly packed structures (gimple
and some tree structures in gcc).
Thanks,
Kugan
>> Alternatively, we maybe able to get this info from dwarf info when we compile with -g ?
>
> I doubt you can. He wants to know if an instruction is a spill location. The location of a variable might be recorded in -g (if it was an user variable) but not that does present the data for all temps being spilled.
>
> I think the patch is actually a good one in general just needs some cleanup.
>
> As for these comments:
>>> For example, GCC calls `output_asm_insn' directly from the `define_insn'
>>> definition in the aarch64.md file without an insn object(`output_asm_insn'
>>> calls `output_asm_operand_names').
>>> This occurs in "*cb<optab><mode>1" and
>>> "*aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult".
>
> Spills in GCC will always be via the mov* patterns (they are special).
> Now really *aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult should be fixed for a different reason; it does unneeded work. The fix would be something like (untested):
> {
> operands[2] = GEN_INT (aarch64_fpconst_pow_of_2 (operands[2]));
> return "fcvtz<su>\t%<GPI:w>0, %<GPF:s>1, %2";
> }
>
> Thanks,
> Andrew
>
>
> -----Original Message-----
> From: linaro-toolchain [mailto:linaro-toolchain-bounces@lists.linaro.org] On Behalf Of Kugan Vivekanandarajah
> Sent: Saturday, August 26, 2017 12:40 AM
> To: Renato Golin <renato.golin(a)linaro.org>
> Cc: Jim Wilson <jim.wilson(a)linaro.org>; hpc-sig-devel(a)linaro.org; Linaro Toolchain <linaro-toolchain(a)lists.linaro.org>
> Subject: Re: [hpc-sig-devel] GCC extensions for `hcqc'
>
> Hi,
>
> On 26 August 2017 at 04:04, Renato Golin <renato.golin(a)linaro.org> wrote:
>> +linaro-toolchain, hoping to get more eyes into it.
>>
>> cheers,
>> --renato
>>
>> On 25 August 2017 at 17:59, Masaki Arai <masaki.arai(a)linaro.org> wrote:
>>> Hi,
>>>
>>> I extended GCC 7.1(or GCC 7.2) for `hcqc'.
>>> I would be grateful if you could give me a comment about whether this
>>> extension is acceptable and whether this extension should be pushed
>>> upstream.
>
> I think this is a useful info. However there might be pushback from upstream maintainers as this makes the structure bigger by adding a field. This could have implications for memory usage of the compiler.
> Alternatively, we maybe able to get this info from dwarf info when we compile with -g ? Jim may have some input here (cc ing him).
>
> Thanks,
> Kugan
>
>>>
>>> The extended GCC's output using the option ` -fverbose-asm' is as
>>> follows:
>>>
>>> ldr w0, [x29,48] // tmp433, j(8-byte Folded Spill)
>>> ^^^^^^^^^^^^^^^^^^^ This
>>> code shows that this instruction accesses a memory area for spill
>>> codes.
>>> I made the following changes to GCC 7.1(or GCC 7.2).
>>> The related files are under `hcqc/patch/gcc-7.1.0-add'.
>>>
>>> (1) rtl.h
>>>
>>> I added flag information to `struct mem_attrs' that means whether it
>>> is a spill memory area or not.
>>>
>>> +
>>> + /* True if the MEM is for spill. */
>>> + bool for_spill_p;
>>>
>>> Also, I added an access macro for this additional field.
>>>
>>> + /* For a MEM rtx, true if its MEM is for spill. */ #define
>>> + MEM_FOR_SPILL_P(RTX) (get_mem_attrs (RTX)->for_spill_p)
>>> +
>>>
>>> (2) emit-rtl.c
>>>
>>> I added a code to turn on flags for spill memory area in function
>>> `set_mem_attrs_for_spill'.
>>>
>>> + attrs.for_spill_p = true;
>>>
>>> (3) final.c
>>>
>>> I added code to print that information in function
>>> `output_asm_operand_names'
>>> if the memory is a spill memory area,
>>>
>>> +
>>> + if (MEM_P (op) && MEM_FOR_SPILL_P (op))
>>> + {
>>> + HOST_WIDE_INT size = MEM_SIZE (op);
>>> + fprintf (asm_out_file, " (" HOST_WIDE_INT_PRINT_DEC "-byte
>>> + Folded
>>> Spill)", size);
>>> + }
>>>
>>> The above changes are implemented similarly as Clang/LLVM.
>>> Unfortunately, it is difficult for GCC to print the above "(?-byte
>>> Folded Spill)"
>>> for memory access instructions only in the same manner as Clang/LLVM.
>>> The reason is that GCC executes the above `output_asm_operand_names'
>>> even in situations where any instruction object(insn) does not exist
>>> when outputting assembly code.
>>> For example, GCC calls `output_asm_insn' directly from the `define_insn'
>>> definition in the aarch64.md file without an insn object(`output_asm_insn'
>>> calls `output_asm_operand_names').
>>> This occurs in "*cb<optab><mode>1" and
>>> "*aarch64_fcvt<su_optab><GPF:mode><GPI:mode>2_mult".
>>>
>>> From this fact, `hcqc' extracts and accumulates memory access
>>> instructions from the assembly code with the comment "(?-byte Folded
>>> Spill)".
>>>
>>> The above extensions are commonly available on almost any architecture.
>>> Also, these extensions do not affect the execution of the resulting
>>> assembly code since additional outputs are only in comments.
>>>
>>> Best regards,
>>> --
>>> --------------------------------------
>>> Masaki Arai
>>>
>> _______________________________________________
>> linaro-toolchain mailing list
>> linaro-toolchain(a)lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
> _______________________________________________
> linaro-toolchain mailing list
> linaro-toolchain(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
== Progress ==
o Linaro GCC/Validation
* Delivered monthly source snapshots
* Released GCC 6 and 7 2017.08 binary releases
* Completed PR 80287:
- Added new testcase on trunk and GCC 7 branch.
- Fix backported on gcc-6-branch.
* Investigating upstream bugzilla PR81863
* Other patches are still pending on upstream reviews
o Misc
* Various meetings and discussions.
== Plan ==
o Off until Aug 31th
o PR81863, ...
