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 dg-add-options
-mfloat-abi=hard
On 27 November 2017 at 17:47, Kyrill Tkachov
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 costs [1] fail when GCC is configured
>&g
stophe for pointing this out.
[1] https://gcc.gnu.org/ml/gcc-patches/2017-11/msg02149.html
Charles Baylis
* gcc.target/arm/addr-modes-float.c (ATTR): New define.
(POST_STORE): Pass ATTR as 2nd argument.
(POST_LOAD): Likewise.
(POST_STORE_VEC): Likewise.
* gcc.
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.
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.
On 20 November 2017 at 21:09, Charles Baylis 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.
Bootstrap built successfully using qem
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 information, it should be encoded this
>
On 15 September 2017 at 18:01, Kyrill Tkachov
wrote:
>
> On 15/09/17 16:38, Charles Baylis wrote:
>>
>> On 13 September 2017 at 10:02, Kyrill Tkachov
>> wrote:
>>>
>>> Hi Charles,
>>>
>>> On 12/09/17 09:34, charles.bay...@linaro.org
On 24 October 2017 at 19:40, Andrew Pinski wrote:
> On Tue, Oct 24, 2017 at 11:27 AM, Charles Baylis
> wrote:
>> In ILP32, GCC fails to merge pointer arithmetic into the addressing
>> mode of a load instruction, as
>> add w0, w0, w1, lsl 2
>>
On 30 October 2017 at 08:52, Janne Blomqvist wrote:
> On Tue, Oct 24, 2017 at 9:27 PM, Charles Baylis
> wrote:
>> 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.
&
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
* gcc.target/aarch64/symbol-range.c: Add dg-skip-if for ilp32 targets
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:
Charle
on aarch64-linux-gnu.
gcc/testsuite:
Charles Baylis
* gcc.target/aarch64/extend.c (ldr_uxtw): Add xfail for ilp32.
(ldr_uxtw0): Likewise.
(ldr_sxtw): Likewise.
(ldr_sxtw0): Likewise.
From 70d43eb4f783d434e7996ebdde40b4ffea4a4a20 Mon Sep 17 00:00:00 2001
From: Char
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/testsui
On 13 September 2017 at 10:02, Kyrill Tkachov
wrote:
> Hi Charles,
>
> On 12/09/17 09:34, charles.bay...@linaro.org wrote:
>>
>> From: Charles Baylis
>>
>> This patch moves the calculation of costs for MEM into a
>> separate function, and reforms the cal
*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 Baylis
Date: Thu, 14 Sep 2017 12:47:41 +01
On 13 September 2017 at 10:02, Kyrill Tkachov
wrote:
> Hi Charles,
>
> On 12/09/17 09:34, charles.bay...@linaro.org wrote:
>>
>> From: Charles Baylis
>>
>> Add bus widths. These use the approximation that v7 and later cores have
>> 64bit data bus width,
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))
>> + {
>> + *cost += current_tune->addr_
From: Charles Baylis
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 added.
In this patch, the calculation
From: Charles Baylis
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
* config/arm/arm-protos.h (enum arm_addr_mode_op): New
From: Charles Baylis
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_params.
(Not intended to be 100
From: Charles Baylis
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
* config/arm/arm-protos.h (struct tune_params): New field
bus_width
On 9 June 2017 at 15:13, Richard Earnshaw (lists)
wrote:
> On 21/02/17 16:54, charles.bay...@linaro.org wrote:
>> From: Charles Baylis
>>
>> This patch adds support for modelling the varying costs of
>> different addressing modes. The generic cost table treats
>&g
On 9 June 2017 at 14:59, Richard Earnshaw (lists)
wrote:
> On 21/02/17 16:54, charles.bay...@linaro.org wrote:
>> From: Charles Baylis
>>
>> This patch moves the calculation of costs for MEM into a
>> separate function, and reforms the calculation into two
>> p
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 interface,
> that would tie us to
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, wrote:
> From: Charles Baylis
>
> Hi Ramana,
>
> This patch set continues previous work on fixing the co
From: Charles Baylis
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/topic/com.arm.doc.uan0015b
From: Charles Baylis
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 added.
In this patch, the calculation
From: Charles Baylis
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 patch set as follows:
Background:
The
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
* config/arm/arm-protos.h (arm_emit_long_call_profile): New function.
* config/arm/arm.c (arm_emit_long_call_profile_in
, 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
* config/arm/arm-protos.h (arm_emit_long_call_profile): New function.
* config/arm/
none, 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
Date: Thu, 11 Feb 2016 18:07:00 +
Subject: [PATCH] [ARM] PR69770 fix -mlong-calls with -pg
gcc/ChangeLog:
2016-02-12 Charles B
On 9 February 2016 at 17:08, Kyrill Tkachov wrote:
>
> On 09/02/16 17:00, Charles Baylis wrote:
>>
>> On 8 February 2016 at 11:42, Kyrill Tkachov
>> wrote:
>>>
>>> Hi Charles,
>>>
>>>
>>> On 03/02/16 18:59, charles.bay...@
Committed to trunk as r233252
On 9 February 2016 at 17:07, Charles Baylis wrote:
> On 8 February 2016 at 11:42, Kyrill Tkachov
> wrote:
>
>> On 03/02/16 18:59, charles.bay...@linaro.org wrote:
>>> --- a/gcc/config/arm/arm.c
>>> +++ b/gcc/config/arm
nd_vec_perm_d
>> *d)
>> in0 = d->op0;
>> in1 = d->op1;
>> - if (BYTES_BIG_ENDIAN)
>> + if (is_swapped)
>> {
>> std::swap (in0, in1);
>> - high = !high;
>> }
>
>
> remove the braces around th
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;
>> +}
>> +
>> +int
>> +main
From: Charles Baylis
gcc/ChangeLog:
2016-02-03 Charles Baylis
PR target/68532
* config/arm/arm.c (neon_endian_lane_map): New function.
(neon_vector_pair_endian_lane_map): New function.
(arm_evpc_neon_vuzp): Allow for big endian lane order.
* config
From: Charles Baylis
gcc/ChangeLog:
2016-02-03 Charles Baylis
PR target/68532
* config/arm/arm.c (arm_evpc_neon_vzip): Allow for big endian lane
order.
* config/arm/arm_neon.h (vzipq_s8): Adjust shuffle patterns for big
endian.
(vzipq_s16
From: Charles Baylis
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-linux-gnueabihf. The new test passes for
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: gcc.dg/torture/vshuf-v4hi.c -O2 (internal com
ping^2
On 13 January 2016 at 13:37, Charles Baylis wrote:
> ping
>
> On 16 December 2015 at 17:44, Charles Baylis
> wrote:
>> Hi
>>
>> This patch addresses incorrect recognition of VEC_PERM_EXPRs as VUZP
>> and VZIP on armeb-* targets. It also fixes the def
ping
On 16 December 2015 at 17:44, Charles Baylis 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 which use incorrect lane
> specif
previously used. There are also a
few new PASSes.
Patch 1 (vuzp):
gcc/ChangeLog:
2015-12-15 Charles Baylis
* config/arm/arm.c (arm_neon_endian_lane_map): New function.
(arm_neon_vector_pair_endian_lane_map): New function.
(arm_evpc_neon_vuzp): Allow for big endian
Applied to trunk as r231077.
On 26 November 2015 at 09:43, James Greenhalgh wrote:
> On Thu, Nov 26, 2015 at 09:41:15AM +0000, Charles Baylis wrote:
>> Hi James,
>>
>> Ping. This needs an ack from an AArch64 reviewer/maintainer
>
> Fine by me, it will considerably c
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
> floating point register for TARGET_HARD
Backported r227407 to gcc-5-branch following approval on IRC. The
patch applied without conflicts.
2015-11-16 Charles Baylis
Backport from mainline r227407
PR ipa/67280
* cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external
in new callgraph edge
tion, 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.
From d8110f141a449
On 9 November 2015 at 13:35, Ramana Radhakrishnan
wrote:
>
>
> On 08/11/15 00:26, charles.bay...@linaro.org wrote:
>> From: Charles Baylis
>>
>> Charles Baylis
>>
>> * config/arm/neon.md (neon_vld1_lane): Remove error for invalid
>>
h those changes, the attached patch was applied as r230142
From 4a05b67a1757e88e1989ce7515cd10de0a6def1c Mon Sep 17 00:00:00 2001
From: Charles Baylis
Date: Wed, 17 Jun 2015 17:08:30 +0100
Subject: [PATCH 1/4] [ARM] PR63870 Add qualifiers for NEON builtins
gcc/ChangeLog:
Charles Baylis
PR ta
On 11 November 2015 at 12:10, Kyrill Tkachov wrote:
>
> On 11/11/15 12:08, Charles Baylis wrote:
>>
>> On 11 November 2015 at 11:22, Kyrill Tkachov
>> wrote:
>>>
>>> Hi Charles,
>>>
>>> On 08/11/15 00:26, charles.bay...@linaro.org wrote
On 11 November 2015 at 11:22, Kyrill Tkachov wrote:
> Hi Charles,
>
> On 08/11/15 00:26, charles.bay...@linaro.org wrote:
>>
>> From: Charles Baylis
>>
>> Charles Baylis
>>
>> * config/arm/neon.md (neon_vld1_lane): Remov
From: Charles Baylis
Charles Baylis
* config/arm/neon.md (neon_vld1_lane): Use internal_error for
invalid lane number.
(neon_vst1_lane): Likewise.
(neon_vld2_lane): Likewise.
(neon_vst2_lane): Likewise.
(neon_vld3_lane): Likewise
From: Charles Baylis
Charles Baylis
* config/arm/neon.md (neon_vld1_lane): Remove error for invalid
lane number.
(neon_vst1_lane): Likewise.
(neon_vld2_lane): Likewise.
(neon_vst2_lane): Likewise.
(neon_vld3_lane): Likewise
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
PR target/63870
* 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_lane
From: Charles Baylis
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,
described below.
[ARM] PR63870 Add
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
PR target/63870
* config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator
qualifier_struct_load_store_lane_index.
(builtin_arg): New enumerator NEON_ARG_STRUCT_LOAD_STORE_LANE_INDEX
On 4 November 2015 at 08:05, Ramana Radhakrishnan
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.org/ml/gcc-patches/2015-06/msg01593.html]
&
at, I 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
Date: Wed, 28 Oct 2015 18:
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?
> (define_insn "neon_vec_unpack_lo_"
>
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 failed. */
>>
On 7 October 2015 at 00:59, wrote:
> From: Charles Baylis
>
> 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 l
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
PR target/63870
* 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_lane
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
PR target/63870
* config/arm/arm-builtins.c (enum arm_type_qualifiers): New enumerator
qualifier_struct_load_store_lane_index.
(builtin_arg): New enumerator NEON_ARG_STRUCT_LOAD_STORE_LANE_INDEX
From: Charles Baylis
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 duplicate arm_neon_lane_bounds function
On 7 September 2015 at 09:35, Charles Baylis wrote:
>>> >gcc/ChangeLog:
>>> >
>>> >2015-08-28 Charles Baylis
>>> >
>>> > * cgraphunit.c (cgraph_node::create_wrapper): Set
>>> > can_throw_external
>>> >
> handled
> locally.
OK.
>> >gcc/ChangeLog:
>> >
>> >2015-08-28 Charles Baylis
>> >
>> > * cgraphunit.c (cgraph_node::create_wrapper): Set
>> > can_throw_external
>> > in new callgraph edge.
>> Ultimatel
est 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
* cgraphunit.c (cgraph_node::create_wrapper): Set can_throw_external
in new callgraph edge.
0001-fix-up-can_throw_external-in-cgr
On 31 July 2015 at 10:34, Ramana Radhakrishnan
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 need 3 iterations
> rather th
On 17 July 2015 at 09:32, James Greenhalgh 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 compilation
> pipeline. The pr
Committed as obvious r226061.
gcc/ChangeLog:
2015-07-22 Charles Baylis
* config/aarch64/aarch64-simd.md (vec_store_lanesoi_lane): Fix
typo in attribute.
From 7d98f7fc82cfc3012b460e4f4f91200fedcb04db Mon Sep 17 00:00:00 2001
From: Charles Baylis
Date: Tue, 21 Jul 2015 16:54
Ping?
On 26 June 2015 at 20:14, Charles Baylis 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
>
On 6 July 2015 at 11:18, Alan Lawrence 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 conflicts, I suggest
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
gcc/testsuite/ChangeLog:
Charles Baylis
* 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/vld2_lane_p8_indices_1.c: New
gcc/ChangeLog:
Charles Baylis
* 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_lane) Reverse lane numbers for
big-endian
gcc/ChangeLog:
Charles Baylis
* 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
argument qualifiers
On 18 June 2014 at 11:06, Ramana Radhakrishnan
wrote:
> On Tue, Jun 17, 2014 at 4:03 PM, Charles Baylis
> wrote:
>> Your mention of larger vector modes prompted me to check that the
>> patch has the desired result with them. In fact, the costs are
>> estimated inc
Ping?
On 11 June 2015 at 00:42, Charles Baylis wrote:
> [resending, as previous version was rejected from the list for html]
>
> On 11 June 2015 at 00:38, Charles Baylis wrote:
>>
>>
>> On 8 June 2015 at 10:44, Alan Lawrence wrote:
>>> Oh, have you teste
On 8 June 2015 at 10:33, Alan Lawrence 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 / moves.
Kugan
On 14 April 2015 at 14:45, Alan Lawrence 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. However, thanks for
On 10 December 2014 at 10:34, Alan Lawrence 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 __AARCH64_LANE_CHECK, those
> patch
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
* config/aarch64/aarch64-builtins.c
(aarch64_types_storestruct_lane_qualifiers): Mark last argument with
qualifier_struct_load_store_lane_index.
gcc/testsuite/ChangeLog:
Charles Baylis
* gcc.target
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
* config/aarch64/arm_neon.h (__ST2_LANE_FUNC): Add explicit lane bounds
check.
(__ST3_LANE_FUNC): Likewise.
(__ST4_LANE_FUNC): Likewise.
gcc/testsuite/ChangeLog:
Charles Baylis
* gcc.target
From: Charles Baylis
gcc/ChangeLog
Charles Baylis
* config/aarch64/arm_neon.h (__LD2_LANE_FUNC): Add explicit lane
bounds check.
(__LD3_LANE_FUNC): Likewise.
(__LD4_LANE_FUNC): Likewise
gcc/testsuite/ChangeLog:
Charles Baylis
* gcc.target
From: Charles Baylis
gcc/ChangeLog:
Charles Baylis
PR target/63870
* config/aarch64/aarch64-builtins.c (enum aarch64_type_qualifiers):
Add qualifier_struct_load_store_lane_index.
(aarch64_types_loadstruct_lane_qualifiers): Use
From: Charles Baylis
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 intrinsics, these are checked
On 5 December 2014 at 11:45, Alan Lawrence 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 and
> ve
On 20 November 2014 07:49, Marcus Shawcroft wrote:
> On 19 November 2014 19:05, Charles Baylis wrote:
>
>> PR target/63870
>> * config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
>> expression to aarch64_simd_lane_bounds.
>
On 19 November 2014 16:51, Marcus Shawcroft wrote:
>
> In the meantime could you respin the patch to drop the default args
> and pass explicit NULL ?
Done.
Charles Baylis
PR target/63870
* config/aarch64/aarch64-builtins.c (aarch64_simd_expand_args): Pass
e
On 19 November 2014 16:42, Alan Lawrence 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}_lane
>
> I'll handle the first two. Do we have a plan for ld2/3/4 ?
I'm happy to do those
Charles
On 12 November 2014 15:35, Alan Lawrence 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 all of the cal
;s patch) is needed to address
the other intrinsics 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?
Charles Baylis
* config/aarch64/aarch64
Resending as text/plain
On 11 November 2014 15:14, Charles Baylis wrote:
>
>
> On 6 November 2014 10:19, Alan Lawrence wrote:
>>
>> This generates out-of-range errors at compile- (rather than assemble-)time
>> for the vqdm*_lane intrinsics, and also provides a sing
On 24 October 2014 11:23, Marcus Shawcroft wrote:
> On 23 October 2014 18:51, Charles Baylis 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 to trunk as r216671 and r216672.
lignment of the
\'s when reading the patch is just due to the effect of the unified
diff misaligning 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?
GTM(but I can't approve it). Thanks 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
--
Charles Baylis
* config/aarch64/aarch64-builtins.c
On 26 September 2014 13:47, Tejas Belagod 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 to
> give a more opt
From: Charles Baylis
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
with qemu, and also
From: Charles Baylis
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 has been removed, as this
From: Charles Baylis
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
with qemu, and also causes no
1 - 100 of 152 matches
Mail list logo
