Re: [PATCH] ARM testsuite: force hardfp for addr-modes-float.c

On 30 November 2017 at 15:56, Kyrill Tkachov wrote: > > So is it the case that you don't run any arm tests that include arm_neon.h > in your configuration? No, it is only the case that any arm test which includes arm_neon.h (in fact, any system header) *and* uses

Re: [PATCH] ARM testsuite: force hardfp for addr-modes-float.c

On 27 November 2017 at 17:47, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > Hi Charles, > > On 27/11/17 17:03, Charles Baylis wrote: >> >> Some of the new tests in addr-modes-float.c, which were introduced for >> the rework of addressing modes cost

[PATCH] ARM testsuite: force hardfp for addr-modes-float.c

Christophe for pointing this out. [1] https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02149.html Charles Baylis <charles.bay...@linaro.org> * gcc.target/arm/addr-modes-float.c (ATTR): New define. (POST_STORE): Pass ATTR as 2nd argument. (POST_LOAD): Likewise. (POST_STOR

Re: [PATCH 2/3] [ARM] Refactor costs calculation for MEM.

On 23 November 2017 at 10:01, Kyrill Tkachov wrote: > > Thanks, these are ok for trunk. > They were originally posted way before stage 3 and this is just a rework, > so it's acceptable at this stage as far as I'm concerned. Thanks. Committed to trunk as r255111.

Re: [PATCH 3/3] [ARM] Add table of costs for AAarch32 addressing modes.

On 15 September 2017 at 17:57, Kyrill Tkachov wrote: > > Thanks, this is ok once the prerequisites are sorted. Patch 1 was abandoned, and a later version of patch 2 has been committed, so this was applied to trunk as r255112.

Re: [PATCH 2/3] [ARM] Refactor costs calculation for MEM.

On 20 November 2017 at 21:09, Charles Baylis <charles.bay...@linaro.org> wrote: > I have modified this patch accordingly. Patch 1 is no longer needed. > > Passes "make check" (with patch 3) on arm-linux-gnueabihf with no > regressions. Bootstrap is in progress. Bootst

Re: [PATCH 1/3] [ARM] Add bus_width_bits to tune_params

On 15 September 2017 at 18:01, Kyrill Tkachov wrote: > From what I can tell Ramana and Richard preferred to encode this attribute > as > a tuning struct property rather than an inline conditional based on > arm_arch7. > I agree that if we want to use that

Re: [PATCH 2/3] [ARM] Refactor costs calculation for MEM.

On 15 September 2017 at 18:01, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > > On 15/09/17 16:38, Charles Baylis wrote: >> >> On 13 September 2017 at 10:02, Kyrill Tkachov >> <kyrylo.tkac...@foss.arm.com> wrote: >>> >>> Hi Charles

Re: [AArch64, testsuite] gcc.target/aarch64/extend.c: xfails for ilp32

On 24 October 2017 at 19:40, Andrew Pinski <pins...@gmail.com> wrote: > On Tue, Oct 24, 2017 at 11:27 AM, Charles Baylis > <charles.bay...@linaro.org> wrote: >> In ILP32, GCC fails to merge pointer arithmetic into the addressing >> mode of a load instruction, as >

Re: [AArch64, testsuite] gfortran.dg/ieee/ieee_8.f90: xfail for aarch64+ilp32

On 30 October 2017 at 08:52, Janne Blomqvist <blomqvist.ja...@gmail.com> wrote: > On Tue, Oct 24, 2017 at 9:27 PM, Charles Baylis > <charles.bay...@linaro.org> wrote: >> The test is already marked xfail for aarch64*-*-gnu, but this needs to >> be changed to aar

[AArch64, testsuite] gcc.target/aarch64/symbol-range.c: skip for ilp32

This test relies on an object size >4GB, so cannot be compiled for ILP32. Shows the expected FAIL->UNSUPPORTED on aarch64-linux-gnu_ilp32, no regressions for aarch64-linux-gnu. Charles Baylis <charles.bay...@linaro.org> * gcc.target/aarch64/symbol-range.c: Add dg-skip-

[AArch64, testsuite] gfortran.dg/ieee/ieee_8.f90: xfail for aarch64+ilp32

The test is already marked xfail for aarch64*-*-gnu, but this needs to be changed to aarch64*-*-gnu* in order to match aarch64-linux-gnu_ilp32. Test was previously xfail'd in [1]. Shows the expected FAIL->XFAILs on aarch64-linux-gnu_ilp32. gcc/testsuite: Charles Baylis <charl

[AArch64, testsuite] gcc.target/aarch64/extend.c: xfails for ilp32

ons on aarch64-linux-gnu. gcc/testsuite: Charles Baylis <charles.bay...@linaro.org> * gcc.target/aarch64/extend.c (ldr_uxtw): Add xfail for ilp32. (ldr_uxtw0): Likewise. (ldr_sxtw): Likewise. (ldr_sxtw0): Likewise. From 70d43eb4f783d434e7996ebdde40b4ffea4a4a20 M

[AArch64, testsuite] gcc.target/aarch64/fmul_fcvt_1.c: ilp32 fixes

This test includes the implicit assumption that the 'long' type on AArch64 is a 64 bit type. This is not the case for ILP32, so use 'long long' instead. Shows the expected new PASSes on aarch64-linux-gnu_ilp32, no regressions on aarch64-linux-gnu, gcc/testsuite: Charles Baylis <charles.

Re: [PATCH 2/3] [ARM] Refactor costs calculation for MEM.

On 13 September 2017 at 10:02, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > Hi Charles, > > On 12/09/17 09:34, charles.bay...@linaro.org wrote: >> >> From: Charles Baylis <charles.bay...@linaro.org> >> >> This patch moves the calculation

Re: [PATCH 3/3] [ARM] Add table of costs for AAarch32 addressing modes.

>> + { >> + *cost += current_tune->addr_mode_costs->integer[op_type]; >> + } > > > No need for brackets for single-statement conditionals. Done. From a35fa59f4dc3be42a52519a90bdd2d47e74db086 Mon Sep 17 00:00:00 2001 From: Charles Bayl

Re: [PATCH 1/3] [ARM] Add bus_width_bits to tune_params

On 13 September 2017 at 10:02, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > Hi Charles, > > On 12/09/17 09:34, charles.bay...@linaro.org wrote: >> >> From: Charles Baylis <charles.bay...@linaro.org> >> >> Add bus widths. These use the approx

Re: [PATCH 3/3] [ARM] Add table of costs for AAarch32 addressing modes.

On 13 September 2017 at 10:02, Kyrill Tkachov wrote: > > Please add a comment here saying that the units are in COSTS_N_INSNS > so that we can reduce the temptation to use these in inappropriate contexts. >> + if (VECTOR_MODE_P (mode)) >> + { >> +

[PATCH 2/3] [ARM] Refactor costs calculation for MEM.

From: Charles Baylis <charles.bay...@linaro.org> This patch moves the calculation of costs for MEM into a separate function, and reforms the calculation into two parts. Firstly any additional cost of the addressing mode is calculated, and then the cost of the memory access itself is

[PATCH 3/3] [ARM] Add table of costs for AAarch32 addressing modes.

From: Charles Baylis <charles.bay...@linaro.org> This patch adds support for modelling the varying costs of different addressing modes. The generic cost table treats all addressing modes as having equal cost. gcc/ChangeLog: Charles Baylis <charles.bay...@linaro.org> * co

[PATCH 0/3] [ARM] Addressing mode costs v3

From: Charles Baylis <charles.bay...@linaro.org> This patch set includes the following updates from v2 [1]: . addr_mode_costs table moved into struct tune_params from struct cpu_cost_table (avoids overlap with AArch64 port) . CPU data bus width now comes from a table entry in struct tune_

[PATCH 1/3] [ARM] Add bus_width_bits to tune_params

From: Charles Baylis <charles.bay...@linaro.org> Add bus widths. These use the approximation that v7 and later cores have 64bit data bus width, and earlier cores have 32 bit bus width, with the exception of v7m. Charles Baylis <charles.bay...@linaro.org> * config/arm/

Re: [PATCH 2/2] [ARM] Add table of costs for AAarch32 addressing modes.

On 9 June 2017 at 15:13, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > On 21/02/17 16:54, charles.bay...@linaro.org wrote: >> From: Charles Baylis <charles.bay...@linaro.org> >> >> This patch adds support for modelling the varying costs of >>

Re: [PATCH 1/2] [ARM] Refactor costs calculation for MEM.

On 9 June 2017 at 14:59, Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > On 21/02/17 16:54, charles.bay...@linaro.org wrote: >> From: Charles Baylis <charles.bay...@linaro.org> >> >> This patch moves the calculation of costs for MEM into a

Re: [PATCH][Aarch64] Add vectorized mersenne twister

On 6 June 2017 at 11:07, James Greenhalgh wrote: > If we don't mind that, and instead take a GCC-centric view, we could avoid > namespace polution by using the GCC-internal names for the intrinsics > (__builtin_aarch64_...). As those names don't form a guaranteed

Re: [PATCH 0/2] [ARM] PR61551 addressing mode costs

Ping. Original thread: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01314.html (I will fix the typos which Bernhard found before submitting) On 21 February 2017 at 16:54, <charles.bay...@linaro.org> wrote: > From: Charles Baylis <charles.bay...@linaro.org> > > Hi Raman

[PATCH 2/2] [ARM] Add table of costs for AAarch32 addressing modes.

From: Charles Baylis <charles.bay...@linaro.org> This patch adds support for modelling the varying costs of different addressing modes. The generic cost table treats all addressing modes as having equal cost. The cost table for Cortex-A57 is derived from http://infocenter.arm.com/help

[PATCH 1/2] [ARM] Refactor costs calculation for MEM.

From: Charles Baylis <charles.bay...@linaro.org> This patch moves the calculation of costs for MEM into a separate function, and reforms the calculation into two parts. Firstly any additional cost of the addressing mode is calculated, and then the cost of the memory access itself is

[PATCH 0/2] [ARM] PR61551 addressing mode costs

From: Charles Baylis <charles.bay...@linaro.org> Hi Ramana, This patch set continues previous work on fixing the cost calculations for MEMs which use different addressing modes. It implements the approach we discussed at Linaro Connect BKK16. I have included some notes on the pat

[PATCH ARM v3] PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

eels strongly though. I've noticed in the quoted snippet that there are some GNU coding style errors, so I've respun the patch with those corrected. gcc/ChangeLog: 2016-03-29 Charles Baylis <charles.bay...@linaro.org> * config/arm/arm-protos.h (arm_emit_long_

[PATCH ARM v2] PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

, and Thumb-2 targets. This does not fix a regression, so I don't expect to apply it for GCC6, is it OK for when stage 1 re-opens. gcc/ChangeLog: 2016-03-24 Charles Baylis <charles.bay...@linaro.org> * config/arm/arm-protos.h (arm_emit_long_call_profile): New function. *

[PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

, is this acceptable for trunk now, or should it wait until GCC 7? From 34993396a43fcfc263db5b02b2d1837c490f52ad Mon Sep 17 00:00:00 2001 From: Charles Baylis <charles.bay...@linaro.org> Date: Thu, 11 Feb 2016 18:07:00 + Subject: [PATCH] [ARM] PR69770 fix -mlong-calls with -pg gcc/Cha

Re: [PATCH 2/2] [ARM] PR68532 Fix up vzip recognition for big endian

Committed to trunk as r233252 On 9 February 2016 at 17:07, Charles Baylis <charles.bay...@linaro.org> wrote: > On 8 February 2016 at 11:42, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> > wrote: > >> On 03/02/16 18:59, charles.bay...@linaro.org wrote: >>> ---

Re: [PATCH 1/2] [ARM] PR68532: Fix up vuzp for big endian

On 9 February 2016 at 17:08, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> wrote: > > On 09/02/16 17:00, Charles Baylis wrote: >> >> On 8 February 2016 at 11:42, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> >> wrote: >>> >>> Hi Charles, >>

Re: [PATCH 1/2] [ARM] PR68532: Fix up vuzp for big endian

) in[SIZE]; >> + >> +extern void abort (void); >> + >> +__attribute__ ((noinline)) int >> +test (unsigned short sum, unsigned short *in, int x) >> +{ >> + for (int j = 0; j < SIZE; j += 8) >> +sum += in[j] * x; >> + return sum; >> +} &g

Re: [PATCH 2/2] [ARM] PR68532 Fix up vzip recognition for big endian

9 @@ arm_evpc_neon_vzip (struct expand_vec_perm_d >> *d) >> in0 = d->op0; >> in1 = d->op1; >> - if (BYTES_BIG_ENDIAN) >> + if (is_swapped) >> { >> std::swap (in0, in1); >> - high = !high; >> } > >

[PATCH 2/2] [ARM] PR68532 Fix up vzip recognition for big endian

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: 2016-02-03 Charles Baylis <charles.bay...@linaro.org> PR target/68532 * config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane order. * config/arm/arm_neon.h (vzipq_s8): Ad

[ARM, PATCH v2 0/2] PR68532: Fix VZIP/VUZP recognition for big endian

From: Charles Baylis <charles.bay...@linaro.org> This is an updated patch, which fixes the following issues: . big endian ICE with vshuf-* tests . style issues reported by check_GNU_style.sh This has no regressions with -mfpu=neon, for arm-unknown-linux-gnueabihf and armeb-unknown

[PATCH 1/2] [ARM] PR68532: Fix up vuzp for big endian

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: 2016-02-03 Charles Baylis <charles.bay...@linaro.org> PR target/68532 * config/arm/arm.c (neon_endian_lane_map): New function. (neon_vector_pair_endian_lane_map): New function. (arm_ev

Re: [PATCH] [ARM] PR68532: Fix VUZP and VZIP recognition on big endian

On 1 February 2016 at 17:14, Kyrill Tkachov wrote: > Indeed I see the new passes on armeb-none-eabi. > However, the new FAILs that I see are ICEs, not just vectorisation failures, > so they need to be looked at. > > The ICEs that I see are: > FAIL:

Re: [PATCH] [ARM] PR68532: Fix VUZP and VZIP recognition on big endian

ping^2 On 13 January 2016 at 13:37, Charles Baylis <charles.bay...@linaro.org> wrote: > ping > > On 16 December 2015 at 17:44, Charles Baylis <charles.bay...@linaro.org> > wrote: >> Hi >> >> This patch addresses incorrect recognition of VEC_PERM_EX

Re: [PATCH] [ARM] PR68532: Fix VUZP and VZIP recognition on big endian

ping On 16 December 2015 at 17:44, Charles Baylis <charles.bay...@linaro.org> wrote: > Hi > > This patch addresses incorrect recognition of VEC_PERM_EXPRs as VUZP > and VZIP on armeb-* targets. It also fixes the definition of the > vuzpq_* and vzipq_* NEON intrinsics whi

[PATCH] [ARM] PR68532: Fix VUZP and VZIP recognition on big endian

used. There are also a few new PASSes. Patch 1 (vuzp): gcc/ChangeLog: 2015-12-15 Charles Baylis <charles.bay...@linaro.org> * config/arm/arm.c (arm_neon_endian_lane_map): New function. (arm_neon_vector_pair_endian_lane_map): New function. (arm_evpc_neon_vuzp):

Re: [PATCH 3/4] [ARM] PR63870 Add test cases

Applied to trunk as r231077. On 26 November 2015 at 09:43, James Greenhalgh <james.greenha...@arm.com> wrote: > On Thu, Nov 26, 2015 at 09:41:15AM +, Charles Baylis wrote: >> Hi James, >> >> Ping. This needs an ack from an AArch64 reviewer/maintainer > > Fine

Re: [PATCH] [ARM, Callgraph] Fix PR67280: function incorrectly marked as nothrow

Backported r227407 to gcc-5-branch following approval on IRC. The patch applied without conflicts. 2015-11-16 Charles Baylis <charles.bay...@linaro.org> Backport from mainline r227407 PR ipa/67280 * cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_ex

Re: Incorrect code due to indirect tail call of varargs function with hard float ABI

On 16 November 2015 at 22:24, Kugan wrote: > Please note that we have a sibcall from "broken" to "indirect". > > "direct" is variadic function so it is conforming to AAPCS base standard. > > "broken" is a non-variadic function and will return the value in >

[PATCH v2] [ARM] PR61551 RFC: Improve costs for NEON addressing modes

a pure code clean up of a separate function, why not accept the '387 patch as is, and leave the clean up until GCC 7? Alternatively, this is an updated patch series which changes the costs for MEMs in arm_rtx_costs using the table. Passes make check with no regressions for arm-unknown-linux-gnueabihf on qemu. F

Re: [PATCH 1/4] [ARM] PR63870 Add qualifiers for NEON builtins

t;> + > > Otherwise OK - With those changes, the attached patch was applied as r230142 From 4a05b67a1757e88e1989ce7515cd10de0a6def1c Mon Sep 17 00:00:00 2001 From: Charles Baylis <charles.bay...@linaro.org> Date: Wed, 17 Jun 2015 17:08:30 +0100 Subject: [PATCH 1/4] [ARM] PR63

Re: [PATCH 4b/4] [ARM] PR63870 Remove error for invalid lane numbers

On 9 November 2015 at 13:35, Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> wrote: > > > On 08/11/15 00:26, charles.bay...@linaro.org wrote: >> From: Charles Baylis <charles.bay...@linaro.org> >> >> Charles Baylis <charles.bay...@li

Re: [PATCH 4b/4] [ARM] PR63870 Remove error for invalid lane numbers

On 11 November 2015 at 11:22, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: > Hi Charles, > > On 08/11/15 00:26, charles.bay...@linaro.org wrote: >> >> From: Charles Baylis <charles.bay...@linaro.org> >> >> Charles Baylis <charles.bay..

Re: [PATCH 4b/4] [ARM] PR63870 Remove error for invalid lane numbers

On 11 November 2015 at 12:10, Kyrill Tkachov <kyrylo.tkac...@arm.com> wrote: > > On 11/11/15 12:08, Charles Baylis wrote: >> >> On 11 November 2015 at 11:22, Kyrill Tkachov <kyrylo.tkac...@arm.com> >> wrote: >>> >>> Hi Charles, >

[PATCH 1/4] [ARM] PR63870 Add qualifiers for NEON builtins

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: Charles Baylis <charles.bay...@linaro.org> PR target/63870 * config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator qualifier_struct_load_store_lane_index. (built

[PATCH 4a/4] [ARM] PR63870 Use internal_error() for invalid lane numbers

From: Charles Baylis <charles.bay...@linaro.org> Charles Baylis <charles.bay...@linaro.org> * config/arm/neon.md (neon_vld1_lane): Use internal_error for invalid lane number. (neon_vst1_lane): Likewise. (neon_vld2_lane): Likewise. (ne

[PATCH 4b/4] [ARM] PR63870 Remove error for invalid lane numbers

From: Charles Baylis <charles.bay...@linaro.org> Charles Baylis <charles.bay...@linaro.org> * config/arm/neon.md (neon_vld1_lane): Remove error for invalid lane number. (neon_vst1_lane): Likewise. (neon_vld2_lane): Likewise. (neon_vst2_lan

[PATCH 2/4] [ARM] PR63870 Mark lane indices of vldN/vstN with appropriate qualifier

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: Charles Baylis <charles.bay...@linaro.org> PR target/63870 * config/arm/arm-builtins.c: (arm_load1_qualifiers) Use qualifier_struct_load_store_lane_index. (arm_storestruct_lan

[PATCH v3 0/4] [ARM] PR63870 vldN_lane/vstN_lane error messages

From: Charles Baylis <charles.bay...@linaro.org> Previous discussion: https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00657.html This is a minor update to the previous patch set, fixing one coding style issue in the first patch, and adding a fourth patch for which there are two options, des

Re: [PATCH] [ARM] PR61551 RFC: Improve costs for NEON addressing modes

On 4 November 2015 at 08:05, Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> wrote: > Hi Charles, > > Sorry I missed this completely in my inbox. > > On 31/10/15 03:34, Charles Baylis wrote: >> Hi Ramana, >> >> [revisiting https://gcc.gnu.o

[PATCH] [ARM] PR61551 RFC: Improve costs for NEON addressing modes

will clean up the coding style, check for impact on the AArch64 backend, remove the debug code and in a separate patch improve the tuning for the vector modes. Thanks Charles From b10c6dd7af1f5b9821946783ba9d96b08c751f2b Mon Sep 17 00:00:00 2001 From: Charles Baylis <charles.bay...@linaro.org>

Re: [ARM] Use vector wide add for mixed-mode adds

On 20 October 2015 at 08:54, Michael Collison wrote: > I want to ask a question about existing patterns in neon.md that utilize the > vec_select and all the lanes as my example does: Why are the following > pattern not matched if the target is big endian? >

Re: [PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins

On 12 October 2015 at 11:58, Alan Lawrence wrote: > On 07/10/15 00:59, charles.bay...@linaro.org wrote: >> >> diff --git a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c > > ... >> >> case NEON_ARG_MEMORY: >> /* Check if expand

Re: [PATCH v2 0/3] [ARM] PR63870 vldN_lane/vstN_lane error messages

On 7 October 2015 at 00:59, <charles.bay...@linaro.org> wrote: > From: Charles Baylis <charles.bay...@linaro.org> > > This patch series fixes up the error messages for single lane vector > load/stores, similarly to AArch64. > > make check on arm-linux-gnueab

[PATCH 1/3] [ARM] PR63870 Add qualifiers for NEON builtins

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: Charles Baylis <charles.bay...@linaro.org> PR target/63870 * config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator qualifier_struct_load_store_lane_index. (built

[PATCH v2 0/3] [ARM] PR63870 vldN_lane/vstN_lane error messages

From: Charles Baylis <charles.bay...@linaro.org> This patch series fixes up the error messages for single lane vector load/stores, similarly to AArch64. make check on arm-linux-gnueabihf/qemu completes with no new regressions. Changes since the last version: . removed the dup

[PATCH 2/3] [ARM] PR63870 Mark lane indices of vldN/vstN with appropriate qualifier

From: Charles Baylis <charles.bay...@linaro.org> gcc/ChangeLog: Charles Baylis <charles.bay...@linaro.org> PR target/63870 * config/arm/arm-builtins.c: (arm_load1_qualifiers) Use qualifier_struct_load_store_lane_index. (arm_storestruct_lan

Re: [PATCH] [ARM, Callgraph] Fix PR67280: function incorrectly marked as nothrow

On 7 September 2015 at 09:35, Charles Baylis <charles.bay...@linaro.org> wrote: >>> >gcc/ChangeLog: >>> > >>> >2015-08-28 Charles Baylis <charles.bay...@linaro.org> >>> > >>> > * cgraphunit.c (cgraph_node::create_wra

Re: [PATCH] [ARM, Callgraph] Fix PR67280: function incorrectly marked as nothrow

f the exception is not > handled > locally. OK. >> >gcc/ChangeLog: >> > >> >2015-08-28 Charles Baylis <charles.bay...@linaro.org> >> > >> > * cgraphunit.c (cgraph_node::create_wrapper): Set >> > can_throw_external >&

[PATCH] [ARM, Callgraph] Fix PR67280: function incorrectly marked as nothrow

case, but it seems it's worth getting review for the approach in the mean time. Thanks, Charles gcc/ChangeLog: 2015-08-28 Charles Baylis charles.bay...@linaro.org * cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external in new callgraph edge. 0001-fix-up

Re: [ARM] implement division using vrecpe/vrecps with -funsafe-math-optimizations

On 31 July 2015 at 10:34, Ramana Radhakrishnan ramana.radhakrish...@foss.arm.com wrote: I've tried this in the past and never been convinced that 2 iterations are enough to get to stability with this given that the results are only precise for 8 bits / iteration. Thus I've always believed you

[PATCH] [AArch64] fix typo in vec_store_lanesoi_lanemode

Committed as obvious r226061. gcc/ChangeLog: 2015-07-22 Charles Baylis charles.bay...@linaro.org * config/aarch64/aarch64-simd.md (vec_store_lanesoi_lanemode): Fix typo in attribute. From 7d98f7fc82cfc3012b460e4f4f91200fedcb04db Mon Sep 17 00:00:00 2001 From: Charles Baylis

Re: [PATCH v3] [AArch64] PR63870 Improve error messages for NEON single lane memory access intrinsics

On 17 July 2015 at 09:32, James Greenhalgh james.greenha...@arm.com wrote: This seems an odd limitation, presumably this is a side effect of waiting until expand time to throw an error... It does suggest that we're tackling the problem in the wrong way by pushing this to so late in the

Re: [PATCH v3] [AArch64] PR63870 Improve error messages for NEON single lane memory access intrinsics

Ping? On 26 June 2015 at 20:14, Charles Baylis charles.bay...@linaro.org wrote: Since the last ping, I've tweaked the test cases a bit... Since I've been working on doing the same changes for the ARM backend, I've moved the tests into the advsimd-intrinsics directory, marked as XFAIL for ARM

Re: [PATCH 1/3] [ARM] PR63870 NEON error messages

On 6 July 2015 at 11:18, Alan Lawrence alan.lawre...@arm.com wrote: I note some parts of this duplicate my https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01422.html , which has been pinged a couple of times. Both Charles' patch, and my two, contain parts the other does not... To resolve the

[PATCH 3/3] [ARM] PR63870 NEON error messages

gcc/testsuite/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f32_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics/vld2_lane_f64_indices_1.c: New test. * gcc.target/aarch64/advsimd-intrinsics

[PATCH 0/3] [ARM] PR63870 improve error messages for NEON vldN_lane/vstN_lane

will be done in a future patch. The third patch includes the test cases from the AArch64 version, except that the xfails for arm targets have been removed. If this series gets approved before the AArch64 patch, I will commit the tests with xfail for aarch64 targets. OK for trunk? Charles Baylis (3

[PATCH 1/3] [ARM] PR63870 NEON error messages

gcc/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org * config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerators qualifier_lane_index, qualifier_struct_load_store_lane_index. (arm_expand_neon_args): New parameter. Remove ellipsis. Handle NEON

[PATCH 2/3] [ARM] PR63870 NEON error messages

gcc/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org * config/arm/arm-builtins.c: (arm_load1_qualifiers) Use qualifier_struct_load_store_lane_index. (arm_storestruct_lane_qualifiers) Likewise. * config/arm/neon.md: (neon_vld1_lanemode) Reverse lane

Re: [PATCH] [ARM] Post-indexed addressing for NEON memory access

On 18 June 2014 at 11:06, Ramana Radhakrishnan ramana@googlemail.com wrote: On Tue, Jun 17, 2014 at 4:03 PM, Charles Baylis charles.bay...@linaro.org wrote: Your mention of larger vector modes prompted me to check that the patch has the desired result with them. In fact, the costs

Re: [PATCH] [AArch64] PR63870 Improve error messages for NEON single lane memory access intrinsics

Ping? On 11 June 2015 at 00:42, Charles Baylis charles.bay...@linaro.org wrote: [resending, as previous version was rejected from the list for html] On 11 June 2015 at 00:38, Charles Baylis charles.bay...@linaro.org wrote: On 8 June 2015 at 10:44, Alan Lawrence alan.lawre...@arm.com wrote

Re: [PATCH] [AArch64] PR63870 Improve error messages for NEON single lane memory access intrinsics

On 8 June 2015 at 10:33, Alan Lawrence alan.lawre...@arm.com wrote: Thanks for working on this! I'd been fiddling around with a patch with some similar elements to this, but many trials with union types, subregs, etc., all worsened the register allocation and led to more unnecessary shuffling

Re: [PATCH 1/4] vldN_lane error message enhancements (Q registers)

On 14 April 2015 at 14:45, Alan Lawrence alan.lawre...@arm.com wrote: Assuming/hoping that this patch is proposed for new stage 1 ;), IIRC the approach of using __builtin_aarch64_im_lane_boundsi doesn't work (results in double error messages), and so the patch needs to be rewritten to avoid it.

Re: [PATCH 0/4] [AARCH64,SIMD] PR63870 Improve error messages for single lane load/store

On 10 December 2014 at 10:34, Alan Lawrence alan.lawre...@arm.com wrote: Thanks, Charles. A couple of thoughts. I think the approach in patches 2+3+4 of using __builtin_aarch64_im_lane_boundsi is justified and works quite neatly. Modulo the question of argument ordering and

[PATCH 0/4] [AARCH64,SIMD] PR63870 Improve error messages for single lane load/store

From: Charles Baylis charles.bay...@linaro.org This patch series moves the checking of lane indices for vld[234](q?)_lane and vst[234](q?)_lane intrinsics so that it occurs during builtin expansion. The q register variants are checked directly, but since the d register variants use the same

[PATCH 1/4] vldN_lane error message enhancements (Q registers)

From: Charles Baylis charles.bay...@linaro.org gcc/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org PR target/63870 * config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers): Add qualifier_struct_load_store_lane_index

[PATCH 2/4] vldN_lane error message enhancements (D registers)

From: Charles Baylis charles.bay...@linaro.org gcc/ChangeLog DATE Charles Baylis charles.bay...@linaro.org * config/aarch64/arm_neon.h (__LD2_LANE_FUNC): Add explicit lane bounds check. (__LD3_LANE_FUNC): Likewise. (__LD4_LANE_FUNC): Likewise gcc/testsuite

[PATCH 4/4] vstN_lane error message enhancements (D registers)

From: Charles Baylis charles.bay...@linaro.org gcc/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org * config/aarch64/arm_neon.h (__ST2_LANE_FUNC): Add explicit lane bounds check. (__ST3_LANE_FUNC): Likewise. (__ST4_LANE_FUNC): Likewise. gcc/testsuite

[PATCH 3/4] vstN_lane error message enhancements (Q register)

From: Charles Baylis charles.bay...@linaro.org gcc/ChangeLog: DATE Charles Baylis charles.bay...@linaro.org * config/aarch64/aarch64-builtins.c (aarch64_types_storestruct_lane_qualifiers): Mark last argument with qualifier_struct_load_store_lane_index. gcc/testsuite

Re: [PATCH 0/4][AArch64] PR/63870 Improve handling of errors in SIMD intrinsics

On 5 December 2014 at 11:45, Alan Lawrence alan.lawre...@arm.com wrote: Following on from Charles Baylis' patch to improve the error message when expanding arguments with qualifier_lane_index, this applies similar treatment to __builtin_aarch64_im_lane_boundsi (using for e.g. vset_lane

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

On 20 November 2014 07:49, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 19 November 2014 19:05, Charles Baylis charles.bay...@linaro.org wrote: PR target/63870 * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass expression

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

On 19 November 2014 16:42, Alan Lawrence alan.lawre...@arm.com wrote: Of the calls to aarch64_simd_lane_bounds that remain in aarch64-simd.md: aarch64_get_lanedi aarch64_im_lane_boundsi aarch64_ld{2,3,4}_lanemode I'll handle the first two. Do we have a plan for ld2/3/4 ? I'm happy to do

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

On 19 November 2014 16:51, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: In the meantime could you respin the patch to drop the default args and pass explicit NULL ? Done. DATE Charles Baylis charles.bay...@linaro.org PR target/63870 * config/aarch64/aarch64-builtins.c

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

which have arguments with constant integer range constraints (vget_lane/vset_lane/vldN_lane/vstN_lane/shifts. Richard, Marcus: is such clean up suitable for after stage 1 closes? DATE Charles Baylis charles.bay...@linaro.org * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

On 12 November 2014 15:35, Alan Lawrence alan.lawre...@arm.com wrote: Nice! One nit - can the extra tree argument be a const_tree ? - I'll defer to the maintainers on the use of C++ default arguments in the AArch64 backend. But LGTM. Thanks, good catch. The default parameter will go away once

Re: [PATCH][AArch64] Add bounds checking to vqdm*_lane intrinsics via a qualifier that also flips endianness

Resending as text/plain On 11 November 2014 15:14, Charles Baylis charles.bay...@linaro.org wrote: On 6 November 2014 10:19, Alan Lawrence alan.lawre...@arm.com wrote: This generates out-of-range errors at compile- (rather than assemble-)time for the vqdm*_lane intrinsics, and also provides

Re: [PATCH 2/2] [AARCH64,NEON] Convert arm_neon.h to use new builtins for vld[234](q?)_lane_*

On 24 October 2014 11:23, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 23 October 2014 18:51, Charles Baylis charles.bay...@linaro.org wrote: Otherwise this and the previous 1/2 associated patch look good, can you respin with these tidy ups? OK for trunk? OK /Marcus Committed

Re: [PATCH 2/2] [AARCH64,NEON] Convert arm_neon.h to use new builtins for vld[234](q?)_lane_*

the code with the tabstops. I have respun the patch with those spaces removed. Otherwise this and the previous 1/2 associated patch look good, can you respin with these tidy ups? OK for trunk? From a37d24c57f6c7abe4ade05c1f383e82ebd20c052 Mon Sep 17 00:00:00 2001 From: Charles Baylis charles.bay

Re: [PATCH 1/2] [AARCH64,NEON] Add patterns + builtins for vld[234](q?)_lane_* intrinsics

for this patch. Updated version attached. Patch #2 (https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00678.html) is needed too, but is unchanged. OK for trunk? Charles -- DATE Charles Baylis charles.bay...@linaro.org * config/aarch64/aarch64-builtins.c

[PATCH 0/2] [AARCH64,NEON] Improve vld[234](q?)_lane intrinsics v2

From: Charles Baylis charles.bay...@linaro.org This patch series converts the vld[234](q?)_lane intrinsics to use builtin functions instead of the previous inline assembler syntax. Changes since v1: . the type-punning to change between the array of vector types and the internal builtin types

[PATCH 1/2] [AARCH64,NEON] Add patterns + builtins for vld[234](q?)_lane_* intrinsics

From: Charles Baylis charles.bay...@linaro.org This patch adds new patterns and builtins to represent single lane structure loads instructions, which will be used to implement the vld[234](q?)_lane_* intrinsics. Tested (with the rest of the patch series) with make check on aarch64-oe-linux

[PATCH 2/2] [AARCH64,NEON] Convert arm_neon.h to use new builtins for vld[234](q?)_lane_*

From: Charles Baylis charles.bay...@linaro.org This patch replaces the inline assembler implementations of the vld[234](q?)_lane_* intrinsics with new versions which exploit the new builtin functions added in patch 1. Tested (with the rest of the patch series) with make check on aarch64-oe-linux

Re: [PATCH 2/4] [AARCH64,NEON] Convert arm_neon.h to use new builtins for vld[234](q?)_lane_*

On 26 September 2014 13:47, Tejas Belagod tejas.bela...@arm.com wrote: If we use type-punning, there are unnecessary spills that are generated which is also incorrect for BE because of of the way we spill (st1 {v0.16b - v1.16b}, [sp]) and restore. The implementation without type-punning seems

  1   2   >