Re: [RFA] update ggc_min_heapsize_heuristic()

On 09/04/17 21:06, Markus Trippelsdorf wrote: > On 2017.04.09 at 21:10 +0200, Markus Trippelsdorf wrote: >> On 2017.04.09 at 21:25 +0300, Alexander Monakov wrote: >>> On Sun, 9 Apr 2017, Markus Trippelsdorf wrote: >>> The minimum size heuristic for the garbage collector's heap, before it

Re: [Aarch64] Fix stack checking in ILP32 mode

On 03/04/17 09:25, Eric Botcazou wrote: > Hi, > > this fixes the ICE that has been introduced by the new implementation of > stack > checking in ILP32 mode, hence a regression present on mainline and 6 branch. > I'd also like to mention that the patch only restores the implementation that >

Re: [PATCH, GCC/ARM, stage4] Fix small multiply feature

On 04/04/17 11:30, Thomas Preudhomme wrote: > Small multiply variants of ARM Cortex-M0, Cortex-M0+ and Cortex-M1 were > relying on the old cost model to work when optimizing for speed. These > stopped being used in r241965 which led to these cores starting to use > mul instructions instead of

Re: [PATCH, GCC/testsuite/ARM, stage4] Compile atomic_loaddi_11 for Cortex-R5

On 23/03/17 16:02, Thomas Preudhomme wrote: > Hi, > > gcc.target/arm/atomic_loaddi_11.c testcase contributed in r246365 does > not test the changed code since ARMv7-R does not have division > instructions in ARM state. This patch changes it to target Cortex-R5 > processor instead which does have

Re: [PATCH, GCC/ARM, stage4] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

On 22/03/17 10:25, Thomas Preudhomme wrote: > Hi, > > Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, > as shown by the testcase on this patch. However, LDRD is only atomic > when LPAE extensions is available, which they are not for ARMv7-R. This > commit solve the issue by

Re: [PATCH][AArch64] Optimized implementation of search_line_fast for the CPP lexer

On 20/03/17 17:27, Andreas Schwab wrote: > On Mär 20 2017, "Richard Earnshaw (lists)" <richard.earns...@arm.com> wrote: > >> I don't have access to an ILP32 run-time environment, so I'm not sure >> how I'll be able to check this out. There are some pointer chec

Re: [PATCH][AArch64] Optimized implementation of search_line_fast for the CPP lexer

On 20/03/17 14:53, Andreas Schwab wrote: > On Nov 07 2016, "Richard Earnshaw (lists)" <richard.earns...@arm.com> wrote: > >> This patch contains an implementation of search_line_fast for the CPP >> lexer. It's based in part on the AArch32 (ARM) code but incorpor

Re: [wwwdocs] readings.html maintenance

On 19/03/17 08:03, Gerald Pfeifer wrote: > It turns out both the hp.com link and the arm.com link now redirect > to marketing pages, so instead of chasing forever, I decided to take > them out. > > HPPA and ARM maintainers on copy, if you want to add more appropriate > links, we can definitely do

[aarch64] PR target/80052 Fix typo in aarch64.opt

Fixes the reported typo in aarch64.opt (dummping -> dumping). Committed as obvious. * aarch64.opt(verbose-cost-dump): Fix typo. diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt index 54368848bbb249949921a3018d927c4bd61b1fbd..942a7d558f26f0c8c18b0a94f4f92c575e06f057

Re: [PATCH] [ARM] Cleanup macro TARGET_EITHER

On 17/03/17 12:22, Kyrill Tkachov wrote: > Hi Sudi, > > On 16/03/17 11:11, Sudi Das wrote: >> >> Hi all >> >> This is a cleanup patch to remove the macro TARGET_EITHER. This macro >> seems to have become irrelevant in recent times since its previous >> definition had been commented out and

Re: [RFC][PATCH][AArch64] Improve generic branch cost

On 09/03/17 14:42, Wilco Dijkstra wrote: > Hi, > > Recently we've put a lot of effort into improving ifcvt to use CSEL on > AArch64. > In https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01639.html James determined > the best value for AArch64 code generation. Although this setting is used >

Re: Diagnostics that should not be translated

On 15/03/17 02:43, Martin Sebor wrote: > On 03/12/2017 04:51 PM, Roland Illig wrote: >> Hi, >> >> the gcc.pot file currently contains more than 12000 messages to be >> translated, which is a very high number. Many of these messages are >> diagnostics, and they can be categorized as follows: >> >>

Re: [PATCH][ARM] PR target/79911: Invalid vec_select arguments

On 08/03/17 10:34, Kyrill Tkachov wrote: > Hi all, > > This patch fixes the NEON patterns with Jakub's genrecog verification > improvements: > ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between > vec_select HImode and its operand QImode > ../../gcc/config/arm/neon.md:1338:1:

Re: Poll for option name (Was: [PATCH v6] add -fprolog-pad=N,M option)

On 01/03/17 13:32, Torsten Duwe wrote: > On Wed, Mar 01, 2017 at 11:34:37AM +0000, Richard Earnshaw (lists) wrote: >> On 01/03/17 11:26, Torsten Duwe wrote: >>> >>> However, writing some more documentation and being asked for clarity, >>> I found it more depict

Re: Poll for option name (Was: [PATCH v6] add -fprolog-pad=N,M option)

On 01/03/17 11:26, Torsten Duwe wrote: > On Fri, Feb 17, 2017 at 11:30:29PM -0700, Sandra Loosemore wrote: >>> >>> +@item prolog_pad >>> +@cindex @code{prolog_pad} function attribute >> >> I'm only a documentation maintainer so this is out of my area of >> responsibility, but I really wish we

[PATCH, ARM] Fix PR79742 incorrect scheduler choice.

Due to an oversight, the changes to use the new CPU generation tables forgot to handle selecting a scheduler for a CPU other than the named CPU target. This meant that if, say, cortex-a12 was used, the null scheduler was chosen rather than cortex-a17's scheduler as intended. The fix is to

[PATCH, wwwdocs] Update AArch64 entry in readings.html

This patch tweaks the wording in the entry for AArch64 and also adds a Manufacturer: entry similar to that for ARM. Committed. R. Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.261

[PATCH, wwwdocs] Update list of ARM cpus in readings.html

The list of ARM CPUs in readings.html is now looking rather dated. This patch updates the list to refer to the most commonly available parts (or at least, the product families by which they are known). Committed. R. ? backends.html~ ? index.html.~1.866.~ ? readings.html.~1.260.~ ?

Re: [PATCH 1/5] Handle WORD_REGISTER_OPERATIONS when reloading (subreg(reg))

On 21/02/17 19:53, Matthew Fortune wrote: > Eric Botcazou writes: >>> Agreed. I don't think things like WORD_MODE_OPERATIONS should change >>> rtl semantics, just optimisation decisions. > > Sorry, I did cover two topics in one email. My point was about whether >

Re: [AArch64] Accelerate -fstack-protector through pointer authentication extension

On 18/01/17 17:10, Jiong Wang wrote: >> NOTE, this approach however requires DWARF change as the original LR >> is signed, >> the binary needs new libgcc to make sure c++ eh works correctly. >> Given this >> acceleration already needs the user specify >> -mstack-protector-dialect=pauth >> which

Re: [PATCH][AArch64] Accept more addressing modes for PRFM

On 15/02/17 15:03, Kyrill Tkachov wrote: > Hi Richard, > > On 15/02/17 15:00, Richard Earnshaw (lists) wrote: >> On 03/02/17 17:12, Kyrill Tkachov wrote: >>> Hi all, >>> >>> While evaluating Maxim's SW prefetch patches [1] I noticed that the >>>

Re: [PATCH][AArch64] Accept more addressing modes for PRFM

On 03/02/17 17:12, Kyrill Tkachov wrote: > Hi all, > > While evaluating Maxim's SW prefetch patches [1] I noticed that the > aarch64 prefetch pattern is > overly restrictive in its address operand. It only accepts simple > register addressing modes. > In fact, the PRFM instruction accepts almost

Re: [PATCH, wwwdocs/ARM] Deprecate ARMv5 and ARMv5E support

On 15/02/17 11:23, Thomas Preudhomme wrote: > Hi, > > ARMv5 and ARMv5E architectures have no known implementation. I therefore > suggest that we deprecate these architectures. ARMv5T, ARMv5TE and > ARMv5TEJ would remain supported though. > > Is this ok to commit? > > Best regards, > > Thomas >

Re: [PATCH v5] add -fprolog-pad=N,M option

On 15/02/17 11:12, Marek Polacek wrote: > On Wed, Feb 15, 2017 at 11:01:16AM +0000, Richard Earnshaw (lists) wrote: >> On 13/01/17 12:19, Torsten Duwe wrote: >>> Changes since v4: hopefully addressed all of Sandra's requests >>> and suggestions concerning the doc

Re: [PATCH v5] add -fprolog-pad=N,M option

On 13/01/17 12:19, Torsten Duwe wrote: > Changes since v4: hopefully addressed all of Sandra's requests > and suggestions concerning the documentation snippets, thanks > for the feedback. If it still isn't clear, feel free to rephrase > -- I'm a programmer, not a technical writer. > Generally,

Re: [ARM] Enable descriptors for nested functions in Ada

On 13/11/16 22:31, Eric Botcazou wrote: > Similarly to x86, PowerPC and SPARC, this enables the use of custom run-time > descriptors in Ada, thus eliminating the need for trampolines and executable > stack in presence of pointers to nested functions. > > This still uses bit 1 for the run-time

Re: [Aarch64] Enable descriptors for nested functions in Ada

On 13/11/16 22:30, Eric Botcazou wrote: > Similarly to x86, PowerPC and SPARC, this enables the use of custom run-time > descriptors in Ada, thus eliminating the need for trampolines and executable > stack in presence of pointers to nested functions. > > Tested on Aarch64/Linux, OK for the

Re: [PATCH][testsuite] Require shared effective target for some lto.exp tests

On 24/01/17 14:16, Kyrill Tkachov wrote: > Hi all, > > The tests in this patch fail for me on aarch64-none-elf with: > relocation R_AARCH64_ADR_PREL_PG_HI21 against external symbol > `_impure_ptr' can not be used when making a shared object; recompile > with -fPIC > > I believe since the tests

Re: [Patch AArch64] Use 128-bit vectors when autovectorizing 16-bit float types

On 23/01/17 11:23, James Greenhalgh wrote: > > Hi, > > As subject, we have an oversight in aarch64_simd_container_mode for > HFmode inputs. This results in trunk only autovectorizing to a 64-bit vector, > rather than a full 128-bit vector. > > The fix is obvious, we just need to handle HFmode,

Re: [PATCH/AARCH64] Change -mcpu=thunderx2t99 's -mcpu=native support

On 06/02/17 06:20, Andrew Pinski wrote: > Hi, > When I implemented the -mcpu=thunderx2t99 I did not have the Cavium > partno for ThunderX CN99xx, only the original part no. This patch > adds the new part no for the future versions of the chip. > > OK? Bootstrapped and tested on

Re: [PATCH] Fix exception handling for ILP32 aarch64

On 07/02/17 23:11, Steve Ellcey wrote: > This patch was submitted last year by Andrew Pinski, this is a > resubmit/ping of that patch. > > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html > > During the initial submittal James Greenhalgh asked if this was an ABI change. > I do not

Re: [PATCH][ARM] PR rtl-optimization/68664 Implement TARGET_SCHED_CAN_SPECULATE_INSN hook

On 14/02/17 10:11, Kyrill Tkachov wrote: > Hi all, > > And this is the arm implementation of the hook. It is the same as the > aarch64 one since the two ports > share their instruction types for scheduling purposes. > > Bootstrapped and tested on arm-none-linux-gnueabihf. > > Ok for trunk? > >

Re: [PATCH][AArch64] PR rtl-optimization/68664 Implement TARGET_SCHED_CAN_SPECULATE_INSN hook

On 14/02/17 10:08, Kyrill Tkachov wrote: > Hi all, > > Following up from Segher's patch here is the aarch64 implementation of > the new hook. > It forbids speculation of the integer and floating-point division > instructions as well as the > square-root instructions. > > With this patch the

Re: [PATCH][ARM] Fix assembly comment syntax in -mprint-tune-info

On 07/02/17 14:04, Kyrill Tkachov wrote: > Hi all, > > Currently, -mprint-tune-info gives an assembly file that cannot be > assembled because the branch cost values > are not properly commented. For example: > @.tune parameters > @constant_limit:1 >

Re: Fix profile updating in ifcombine

On 07/02/17 08:37, Christophe Lyon wrote: > Hi, > > > On 6 February 2017 at 17:56, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> On 06/02/17 15:54, Jiong Wang wrote: >>> On 06/02/17 15:26, Jan Hubicka wrote: >>>> I think it i

Re: Fix profile updating in ifcombine

On 06/02/17 15:54, Jiong Wang wrote: > On 06/02/17 15:26, Jan Hubicka wrote: >> I think it is not a regression, just the testcase if fragile and >> depends on outcome >> of ifcombine. It seems it was updated several time in the past. I am >> not quite >> sure what the test is testing. > > They

Re: [PATCH/VECT/AARCH64] Improve cost model for ThunderX2 CN99xx

On 31/01/17 22:34, Andrew Pinski wrote: > On Sat, Jan 28, 2017 at 12:34 PM, Andrew Pinski wrote: >> Hi, >> On some (most) AARCH64 cores, it is not always profitable to >> vectorize some integer loops. This patch does two things (I can split >> it into different patches if

Re: [PATCH/VECT/AARCH64] Improve cost model for ThunderX2 CN99xx

On 28/01/17 20:34, Andrew Pinski wrote: > Hi, > On some (most) AARCH64 cores, it is not always profitable to > vectorize some integer loops. This patch does two things (I can split > it into different patches if needed). > 1) It splits the aarch64 back-end's vector cost model's vector and >

[arm] PR target/79260: Fix header installation for plugins

The recent changes to the header infrastructure for ARM targets broke building of plugins due to missing headers. Patch below, tested on a cross build plus visual examination of the install infrastructure. PR target/79260 * config.gcc (arm*-*-*): Add arm/arm-flags.h and arm/arm-isa.h to

[PATCH][ARM] Fix PR79239 - unrecognized insn after pragma gcc pop_options

It turns out that because the compiler uses a hash table to save the cl_target_option structures it is unsafe to modify the result of build_target_option_node() (doing so will cause the hash lookup to fail). This PR was due to not properly understanding this limitation. The fix is to create

Re: [PATCH AARCH64]XFAIL gcc.target/aarch64/ldp_vec_64_1.c

On 25/01/17 16:49, Bin Cheng wrote: > Hi, > Test gcc.target/aarch64/ldp_vec_64_1.c because we don't choose [base+offset] > addressing mode in IVOPT > on AArch64. Given auto-increment addressing mode is disabled in IVOPT on > AArch64, we can't really test > the addressing mode. I may try to

Re: [PATCH][ARM] PR target/79145 Fix xordi3 expander for immediate operands in iWMMXt

On 25/01/17 10:58, Kyrill Tkachov wrote: > Hi all, > > We're hitting an ICE when expanding a DImode xor with an immediate on > TARGET_IWMMXT: > (insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ]) > (xor:DI (reg:DI 110 [ t1.0_2 ]) > (const_int 85 [0x55]))) ./z32.c:13 -1 > (nil)) >

Re: RFA: Patch for ARM PR77770

On 25/01/17 10:28, Nick Clifton wrote: > Hi Richard, Hi Ramana, > > The patch below is a simple fix for PR0. I am not really > expecting you to agree with it, but I thought that it was worth > posting so that this PR could be looked at again and maybe a better > patch found. (Plus I

Re: [PATCH TEST]Remove xfail for gcc.dg/vect/vect-24.c on ARM targets

On 24/01/17 17:22, Bin Cheng wrote: > Hi, > Test gcc.dg/vect/vect-24.c starts passing after my vectorizer changes, but > not on all targets. For x86_64, looks like other passes still mess up the IR > and prevent it from being vectorized. This patch removes xfail for ARM > targets. > Test

Re: Improve things for PR71724, in combine/if_then_else_cond

On 25/01/17 09:29, Christophe Lyon wrote: > On 25 January 2017 at 10:18, Kyrill Tkachov > wrote: >> >> On 25/01/17 08:53, Christophe Lyon wrote: >>> >>> On 24 January 2017 at 18:15, Bernd Schmidt wrote: On 01/24/2017 06:03 PM,

Re: [PATCH][wwwdocs] Mention new store merging pass for GCC 7

On 23/01/17 16:45, Gerald Pfeifer wrote: > Hi Kyrill, > > On Mon, 23 Jan 2017, Kyrill Tkachov wrote: >> This patch adds a short entry for the store merging pass in GCC 7 to the >> "General Optimizer Improvements" section. > > + A new store merging pass has been added. It will attempt to merge

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 23/01/17 18:00, Andreas Tobler wrote: > On 23.01.17 18:48, Jakub Jelinek wrote: >> On Mon, Jan 23, 2017 at 06:42:15PM +0100, Andreas Tobler wrote: >>> Something like below? >>> >>> If ok, I can commit, right? >>> >>> Thanks, >>> >>> Andreas >>> >>> 2017-01-23 Andreas Tobler

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 21/01/17 20:15, Andreas Tobler wrote: > On 21.01.17 00:42, Jakub Jelinek wrote: >> On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote: > Which is best will depend on what the front/mid ends might have > done to > apply the documented limit. Here I know not enough to

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

On 20/01/17 18:13, Eric Botcazou wrote: >> This seems to have fallen through a crack. Did you get a chance to try >> either of these suggestions? > > So just: > > /* { dg-do run } */ > /* { dg-options "-mapcs-frame -O -foptimize-sibling-calls > -ffunction-sections" > } */ > > in the header

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 20/01/17 19:56, Andreas Tobler wrote: > On 20.01.17 17:12, Richard Earnshaw (lists) wrote: >> On 19/01/17 06:38, Andreas Tobler wrote: >>> On 19.01.17 00:33, Jeff Law wrote: >>>> On 01/18/2017 11:43 AM, Andreas Tobler wrote: >>>>> Hi all, >>&

Re: [1/5][AArch64] Return address protection on AArch64

On 20/01/17 18:30, Jiong Wang wrote: > > On 20/01/17 18:23, Jiong Wang wrote: >> >> OK, the attached patch disable the building of pointer signing code in >> libgcc >> on ILP32 mode, except the macro bit RA_A_SIGNED_BIT is still defined as I >> want to book this bit for ILP32 as LP64 in case we

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

On 01/09/16 10:03, Richard Earnshaw (lists) wrote: > On 01/09/16 10:03, Richard Earnshaw (lists) wrote: >> On 01/09/16 08:47, Eric Botcazou wrote: >>>> Since you're going to need a back-port there should be a PR filed for this. >>> >>> PR target/77439 &g

Re: [1/5][AArch64] Return address protection on AArch64

On 20/01/17 12:36, Jiong Wang wrote: > > > On 20/01/17 11:15, Jiong Wang wrote: >> >> >> On 20/01/17 03:39, Andrew Pinski wrote: >>> On Fri, Jan 6, 2017 at 3:47 AM, Jiong Wang >>> wrote: On 11/11/16 18:22, Jiong Wang wrote: > As described in the cover letter,

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 19/01/17 06:38, Andreas Tobler wrote: > On 19.01.17 00:33, Jeff Law wrote: >> On 01/18/2017 11:43 AM, Andreas Tobler wrote: >>> Hi all, >>> >>> I have the following issue here on aarch64-*-freebsd: >>> >>> (sorry if the format is hardly readable) >>> >>> .. >>>

Re: [PATCH, GCC/testsuite/ARM, ping] Skip optional_mthumb tests if GCC has a default mode

On 13/01/17 18:17, Thomas Preudhomme wrote: > Ping ARM maintainers? (target independent part ACKed by Jeff) > > Best regards, > > Thomas > > On 03/01/17 17:19, Thomas Preudhomme wrote: >> Ping? >> >> Best regards, >> >> Thomas >> >> On 12/12/16 17:52, Thomas Preudhomme wrote: >>> Hi, >>> >>>

Re: [ARM,AArch64][testsuite] Fix format string in AdvSIMD tests

On 17/01/17 08:52, Christophe Lyon wrote: > Hi, > > This patch fixes inconsistencies in the format strings used to emit > error messages when problems are detected in the AdvSIMD tests. They > are not used normally since there is currently no error, but Doko > complained about warnings when he

Re: [PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

On 06/01/17 11:54, Kyrill Tkachov wrote: > Hi all, > > In this wrong-code issue the RTL tries to load a const_vector: > (const_vector:V8QI [ > (const_int 1 [0x1]) > (const_int 0 [0]) > (const_int 1 [0x1]) > (const_int 0 [0]) > (const_int 1 [0x1]) >

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

On 20/01/17 11:54, Jiong Wang wrote: > On 20/01/17 10:30, Christophe Lyon wrote: >> error: 'DWARF_REGNUM_AARCH64_RA_STATE' undeclared (first use in this >> function) >>fs->regs.reg[DWARF_REGNUM_AARCH64_RA_STATE].loc.offset ^= 1; >>

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

On 19/01/17 14:46, Jiong Wang wrote: > Thanks for the review. > > On 19/01/17 14:18, Richard Earnshaw (lists) wrote: >> >>> >>> >>> diff --git a/libgcc/unwind-dw2.c b/libgcc/unwind-dw2.c >>> index >>> 8085a42ace15d53f4cb0c6681717012d9

Re: [Ping~]Re: [5/5][libgcc] Runtime support for AArch64 return address signing (needs new target macros)

On 18/01/17 17:07, Jiong Wang wrote: > On 12/01/17 18:10, Jiong Wang wrote: >> On 06/01/17 11:47, Jiong Wang wrote: >>> This is the update on libgcc unwinder support according to new DWARF >>> proposal. >>> >>> As Joseph commented, duplication of unwind-dw2.c is not encouraged in >>> libgcc, >>>

Re: [2/5][DWARF] Generate dwarf information for -msign-return-address by introducing new DWARF mapping hook

On 17/01/17 15:11, Jiong Wang wrote: > > > On 17/01/17 13:57, Richard Earnshaw (lists) wrote: >> On 16/01/17 14:29, Jiong Wang wrote: >>> >>>> I can see the reason for doing this is if you want to seperate the >>>> interpretion >>>>

Re: [expand] Fix for PR rtl-optimization/79121 incorrect expansion of extend plus left shift

On 18/01/17 21:07, Jeff Law wrote: > On 01/18/2017 11:08 AM, Richard Earnshaw (lists) wrote: >> PR 79121 is a silent wrong code regression where, when generating a >> shift from an extended value moving from one to two machine registers, >> the type of the right shift is for

[expand] Fix for PR rtl-optimization/79121 incorrect expansion of extend plus left shift

PR 79121 is a silent wrong code regression where, when generating a shift from an extended value moving from one to two machine registers, the type of the right shift is for the most significant word should be determined by the signedness of the inner type, not the signedness of the result type.

Re: [2/5][DWARF] Generate dwarf information for -msign-return-address by introducing new DWARF mapping hook

On 16/01/17 14:29, Jiong Wang wrote: > On 13/01/17 18:02, Jiong Wang wrote: >> On 13/01/17 16:09, Richard Earnshaw (lists) wrote: >>> On 06/01/17 11:47, Jiong Wang wrote: >>>> >>>> This patch is an update on DWARF generation for return address signin

Re: [3/5][AArch64] New builtins required by libgcc unwinder

On 06/01/17 11:47, Jiong Wang wrote: > On 11/11/16 18:22, Jiong Wang wrote: >> This patch implements a few ARMv8.3-A new builtins for pointer sign and >> authentication instructions. >> >> Currently, these builtins are supposed to be used by libgcc EH unwinder >> only. They are not public

Re: [2/5][AArch64] Generate dwarf information for -msign-return-address

On 06/01/17 11:47, Jiong Wang wrote: > On 11/11/16 18:22, Jiong Wang wrote: >> This patch generate DWARF description for pointer authentication. >> DWARF value >> expression is used to describe the authentication action. >> >> Please see the cover letter and AArch64 DWARF specification for the >>

Re: [PATCH, ARM] correctly encode the CC reg data flow

On 18/12/16 12:58, Bernd Edlinger wrote: > Hi, > > this is related to PR77308, the follow-up patch will depend on this one. > > When trying the split the *arm_cmpdi_insn and *arm_cmpdi_unsigned > before reload, a mis-compilation in libgcc function __gnu_satfractdasq > was discovered, see [1] for

Re: [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

On 08/12/16 19:50, Bernd Edlinger wrote: > Hi Wilco, > > On 11/30/16 18:01, Bernd Edlinger wrote: >> I attached the completely untested follow-up patch now, but I would >> like to post that one again for review, after I applied my current >> patch, which is still waiting for final review (please

Re: [PATCH, gcc, wwwdocs] Document upcoming Qualcomm Falkor processor support

On 06/01/17 12:11, Siddhesh Poyarekar wrote: > Hi, > > This patch documents the newly added flag in gcc 7 for the upcoming > Qualcomm Falkor processor core. > > Siddhesh > > Index: htdocs/gcc-7/changes.html > === > RCS file:

Re: [ARM] PR 78253 do not resolve weak ref locally

On 11/01/17 16:14, Christophe Lyon wrote: > On 11 January 2017 at 17:13, Christophe Lyon <christophe.l...@linaro.org> > wrote: >> On 11 January 2017 at 16:48, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >>> On 01/12/16 14:27, Christophe Ly

Re: [PATCH][ARM] [gcc] Add __artificial__ attribute to all NEON intrinsics

On 10/01/17 10:40, Tamar Christina wrote: > Hi all, > > This patch adds the __artificial__ and __gnu_inline__ > attributes to the intrinsics in arm_neon.h so that > costs are associated to the user function during profiling > and during debugging the intrinsics are hidden in trace. > > A similar

Re: [PATCH][AArch64] Improve Cortex-A53 scheduling of int/fp transfers

On 10/01/17 17:18, Wilco Dijkstra wrote: > My previous change to the Cortex-A53 scheduler resulted in a 13% regression > on a > proprietary benchmark. This turned out to be due to non-optimal scheduling > of int > to float conversions. This patch separates int to FP transfers from int to >

Re: [ARM] PR 78253 do not resolve weak ref locally

On 01/12/16 14:27, Christophe Lyon wrote: > Hi, > > > On 10 November 2016 at 15:10, Christophe Lyon > wrote: >> On 10 November 2016 at 11:05, Richard Earnshaw >> wrote: >>> On 09/11/16 21:29, Christophe Lyon wrote: Hi,

[arm] Replace command-line option .def files with single definition file

The files arm-cores.def, arm-fpus.def and arm-arches.def are parsed and used in several places and the format is slightly awkward to maintain as they must be parsable in C and by certain scripts. Furthermore, changes to the content that affects every entry is particularly awkward for dealing with

Re: [PATCH] Add support for Fuchsia (OS)

On 12/12/16 21:31, Josh Conner via gcc-patches wrote: > On 12/10/16 3:26 AM, Richard Earnshaw wrote: >> On 08/12/16 22:55, Josh Conner wrote: >>> +arm*-*-fuchsia*) >>> + tm_file="${tm_file} fuchsia.h arm/fuchsia-elf.h glibc-stdint.h" >>> + tmake_file="${tmake_file} arm/t-bpabi" >>> +

Re: [PATCH][ARM] Improve Thumb allocation order

On 30/11/16 17:32, Wilco Dijkstra wrote: > Thumb uses a special register allocation order to increase the use of low > registers. Oddly enough, LR appears before R12, which means that LR must > be saved and restored even if R12 is available. Swapping R12 and LR means > this simple example now

[PATCH 12/21] [arm] Eliminate vfp_reg_type

Remove the VFP_REGS field by converting its meanings into flag attributes. The new flag attributes build on each other describing increasing capabilities. This allows us to do a better job when inlining functions with differing requiremetns on the fpu environment: we can now inline A into B if

[PATCH 20/21] [arm] Remove FEATURES field from FPU descriptions.

Now that everything uses the new ISA features, we can remove the FEATURES field from the FPU descriptions, along with all the macros and definitions associated with it. * arm-fpus.def (ARM_FPU): Remove features field from all definitions. * arm.h (arm_fpu_feature_set): Delete

[PATCH 21/21] [arm] Permit 'auto' in -mfpu.

Now we finally have the infrastructure in place we can now derive details of the FPU from a CPU entry. This patch enables this for the existing cores that already have an explicit FPU in their product names. * arm-fpus.def: Add CNAME field to all FPU definitions. * genopt.sh:

[PATCH 18/21] [arm] Use cl_target_options for configuring the active target.

It now becomes apparent that it would be better to use the the cl_target_options as the basis for calling arm_configure_build_target; it already contains exactly the same fields that we need. I chose not to rewrite the earlier patches as that would make the progression of changes seem less

[PATCH 19/21] [arm] Use ISA feature sets for determining inlinability.

Now that we can construct the build target isa from the cl_target_options data we can use this to determine inlinability. This eliminates the final remaining use of the FPU features field. * arm.c (arm_can_inline_p): Use ISA features for determining inlinability. ---

[PATCH 13/21] [arm] Remove FPU rev field

Similar to the main ISA, we convert the FPU revision into a set of feature bits. This permits a more complex set of capability relationships to be expressed more easily. For now we continue to use the traditional bitmasks. * arm.h (FPU_FL_VFPv2) New feature bit. (FPU_FL_VFPv3,

[PATCH 17/21] [arm] Use arm_active_target for most FP feature tests.

Now that the isa feature bits are all available in arm_active_target we can use that for most of the feature tests that are needed. * arm.h (TARGET_VFPD32): Use arm_active_target. (TARGET_VFP3): Likewise. (TARGET_VFP5): Likewise. (TARGET_VFP_SINGLE): Likewise.

[PATCH 16/21] [arm] Eliminate TARGET_FPU_NAME.

Rather than assuming a specific fpu name has been selected, we work out the FPU from the ISA properties. This is necessary since once we have default FPUs selected by the processor, there will be no explicit entry in the table of fpus to refer to. This also fixes a bug with the code I added

[PATCH 14/21] [arm] Add isa features to FPU descriptions

Similar to the new CPU and architecture ISA feature lists, we now add similar capabilities to each FPU description. We don't use these yet, that will come in later patches. These follow the same style as the newly modified flag sets, but use slightly different defaults that more accurately

[PATCH 15/21] [arm] Initialize fpu capability bits in arm_active_target.

Now that we can describe the FPU with the standard ISA bits we need to initialize them. However, the FPU settings can be changed with target build attributes, so we also need to reset them if things change. This requires a bit of juggling about with the existing code to ensure that the active

[PATCH 09/21] [arm] Rework arm-common to use new feature bits.

This converts the recently added implicit -mthumb support code to use the new data structures. Since we have a very simple query and no initialized copies of the sbitmaps, for now we simply scan the list of features to look for the one of interest. * arm-opts.h (struct

[PATCH 10/21] [arm] Remove remaining references to arm feature sets.

Nothing uses the old feature sets now, so we can delete them entirely. * arm-cores.def: Remove FLAGS field from all core definitions. * arm-arches.def: Likewise. * arm-opts.h (enum processor_type): Remove FLAGS parameter from ARM_CORES macro.

[PATCH 08/21] [arm] Remove insn_flags.

This patch finishes the job of removing insn_flags and moves the logic over to using the new data structures. I've added a new boolean variable to detect when we have ARMv7ve-like capabilities and thus have 64-bit atomic operations since that would be a complex query and expensive to do in full.

[PATCH 11/21] [arm] Delete unused arm_fp_model.

The arm_fp_model enumeration type has only had one useful value since the FPA support was removed, and it's no-longer used anywhere. This patch just cleans that up by removing it. * arm.h (arm_fp_model): Delete. --- gcc/config/arm/arm.h | 8 1 file changed, 8 deletions(-)

[PATCH 07/21] [arm] Use arm_active_target when configuring builtins

This patch uses the new ISA data structure to determine which builtins to add. It entirely eliminates the need for insn_flags to be a global variable, but we're about to delete that in the following patches, so for now we leave it as a global. * arm-builtins.c: Include sbitmap.h.

[PATCH 06/21] [arm] Add new isa quirk bit for Cortex-M3 ldrd issue.

With the new data structures it is trivial to add a new field and we aren't (too) limited as to the number we have. This patch adds a new bit to describe the need for a particular compiler behaviour modification: in this case a quirk in the cortex-m3. * arm-isa.h (enum isa_feature): Add

[PATCH 04/21] [arm] Use arm_active_target for architecture and tune operations.

We now start to make more use of the new data structure. This allows us to eliminate two of the existing static variables, arm_selected_arch and arm_selected tune. * arm.c (arm_selected_tune): Delete static variable. (arm_selected_arch): Likewise.

[PATCH 03/21] [arm] Introduce arm_active_target.

This patch creates a new data structure for carrying around the data relating to the current compilation target. The idea behind this is that this data structure can be updated to reflect the overall compilation target as new information is gathered (from command line options) or architectural

[PATCH 05/21] [arm] Reduce usage of arm_selected_cpu.

Make more use of the new data structure for initializing existing variables. * arm.c (arm_option_override): Use arm_active_target as source of information for arm_base_arch and arm_arch_name. * (arm_file_start): Use arm_active_target for core name. ---

[PATCH 02/21] [arm] Add new isa bits method

This patch adds the new ISA data structures. The idea is to use an sbitmap for carrying these around internally. We don't make much use of this yet, but will increasingly migrate over to this in the following patches. All cores and architectures currently have both old and new encodings for

[PATCH 01/21] [arm] Separte tuning flags from architectural flags in CPU tables.

We start out by separating the 'tuning flags' in a CPU or architecture specification into a new field in the data structures. Because there aren't very many of these (and we'd like to get rid of them entirely, eventually, moving to entries in the tuning tables), we just use a simple unsigned

[PATCH 00/21] [ARM] Automatic selection of FPU

As discussed at this year's Cauldron, it has concerned me for a while now that when a user of the ARM compiler specifies a CPU they also need to specify which floating-point unit it has (even though the choice is almost invariably one). This patch implements the ability to make the selection

Re: [PATCH][ARM] PR target/71436: Restrict *load_multiple pattern till after LRA

On 15/12/16 09:55, Richard Earnshaw (lists) wrote: > On 30/11/16 16:47, Kyrill Tkachov wrote: >> Hi all, >> >> In this awkward ICE we have a *load_multiple pattern that is being >> transformed in reload from: >> (insn 55 67 151 3 (parallel [

Re: [PATCH][ARM] PR target/71436: Restrict *load_multiple pattern till after LRA

On 30/11/16 16:47, Kyrill Tkachov wrote: > Hi all, > > In this awkward ICE we have a *load_multiple pattern that is being > transformed in reload from: > (insn 55 67 151 3 (parallel [ > (set (reg:SI 0 r0) > (mem/u/c:SI (reg/f:SI 147) [2 c+0 S4 A32])) > (set

<    5   6   7   8   9   10   11   12   >