On 19/06/14 16:12, Kyrill Tkachov wrote:
On 19/06/14 16:05, Marat Zakirov wrote:
Hi all,
Here's a patch for PR 61561
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61561).
It fixes ICE.
Thanks for your contribution.
However, this is *really* not the way to submit a patch and is the sort
On 20/06/14 21:28, Richard Henderson wrote:
There aren't too many users of the cmpelim pass, and previously they were all
small embedded targets without an FPU.
I'm a bit surprised that Ramana decided to enable this pass for aarch64, as
that target is not so limited as the block comment for
On 23/06/14 15:01, Richard Henderson wrote:
On 06/23/2014 02:29 AM, Ramana Radhakrishnan wrote:
On 20/06/14 21:28, Richard Henderson wrote:
There aren't too many users of the cmpelim pass, and previously they were all
small embedded targets without an FPU.
I'm a bit surprised that Ramana
=vfpv3-d16/-mfloat-abi=softfp} and
{-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard} on
the AEM.
Ramana
2014-06-25 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* gcc.target/arm/vect-noalign.c: Adjust options.
Index: gcc/testsuite/gcc.target/arm/vect-noalign.c
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
* documentation (README)
* dejanu driver (neon-intrinsics.exp)
* support macros (arm-neon-ref.h, compute-ref-data.h)
* Tests for 2 intrinsics: vaba, vld1
diff --git
On Tue, May 6, 2014 at 5:59 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Monday, May 05, 2014 3:21 PM
To: Richard Earnshaw
Cc: gcc-patches@gcc.gnu.org
Subject: RE:
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
b/gcc/testsuite/gcc.target/arm/neon-intrinsics/unary_op.inc
new file mode 100644
index 000..33f9b5f
--- /dev/null
+++
On Thu, Jun 5, 2014 at 11:04 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
vadd tests also show how to add directives to scan the assembly
output.
diff --git a/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
b/gcc/testsuite/gcc.target/arm/neon-intrinsics/binary_op.inc
new
I'd rather drop the scan-assembler. I'm not convinced that the fragile
nature of this is required. Can you add a note to the README that says
that this is meant to be a complete execution test for the Advanced
SIMD intrinsics and does not cover all the assembler that is
Sure.
generated. If
On Mon, May 5, 2014 at 8:21 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Thursday, May 01, 2014 10:03 PM
To: Bin Cheng
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH ARM]Handle REG addressing mode in
output_move_neon explicitly
On
On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 3a0f99b..44c4990 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,11 @@
2014-06-30 Christophe Lyon
On Tue, Jul 1, 2014 at 11:05 AM, Christophe Lyon
christophe.l...@linaro.org wrote:
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 44c4990..73709c6 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,5 +1,16 @@
2014-06-30 Christophe Lyon
On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo terry@arm.com wrote:
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, June 18, 2014 4:31 PM
To: Terry Guo
Cc: gcc-patches@gcc.gnu.org; Ramana
This is the rebased patch, though the original one doesn't conflict with
latest trunk. Is it OK?
Ok.
Ramana
Thanks,
bin
Hi Ramana,
This is the rebased patch, there is no conflict against latest trunk. I am
still doing some tests. Is it OK if tests are fine?
Also, it depends on patch at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html, I will update that
patch two.
Thanks,
bin
Index:
On Tue, Jul 8, 2014 at 10:59 AM, Alan Lawrence alan.lawre...@arm.com wrote:
No regressions on arm-none-eabi or armeb-none-eabi; also FAIL-PASS on local
copies of the execution-result tests in gcc.target/arm/simd tests (taken
from mainline, these are not present in 4.9).
Ok unless an RM
On Mon, Jun 23, 2014 at 11:05 AM, Alan Lawrence alan.lawre...@arm.com wrote:
As for 4.8, I'm intending to backport the ZIP/UZP/TRN fix for ARM big-endian
in r211369 of mainline. That patches arm_neon.h, so again we need to remove
the OCAML code by which that file is autogenerated...ok?
Ok
On Thu, Jul 3, 2014 at 4:08 PM, Alan Lawrence alan.lawre...@arm.com wrote:
Moving into own thread from
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01895.html
This fixes the compilation failures of gcc.target/arm/simd/vexts64_1.c and
gcc.target/arm/simd/vextu64_1.c that I introduced in r by
On 30/06/14 16:21, Marat Zakirov wrote:
Thank for your attention.
This is OK for trunk - Sorry about the delayed response.
Ramana
Marat.
On Thu, Jun 19, 2014 at 9:19 PM, Yuri Gribov tetra2...@gmail.com wrote:
Thirdly, we also need to fix movhi_bytes (for pre-v4) thumb2_movhi_insn
(for thumb2) and, quite possibly, thumb1_movhi_insn (for thumb1). There
may well be additional changes for movqi variants as well.
A general
On Fri, Jul 18, 2014 at 12:28 PM, Mikael Pettersson
mikpeli...@gmail.com wrote:
John David Anglin writes:
Because the atomic sync functions in config/pa/linux-atomic.c are not
lock free, we need to use
__kernel_cmpxchg for the __sync_lock_release. This was found in
glibc's
On Mon, Jul 14, 2014 at 11:11 AM, Jiong Wang jiong.w...@arm.com wrote:
currently the following testcases are disabled for arm target,
gcc.dg/ira-shrinkwrap-prep-1.c
gcc.dg/ira-shrinkwrap-prep-2.c
gcc.dg/pr10474.c
the reason is on arm target, register r3 is caller-saved. Normally it does
On Sat, Jul 12, 2014 at 11:40 PM, Kugan
kugan.vivekanandara...@linaro.org wrote:
- if (!TARGET_VFP)
-return;
+ if (!TARGET_VFP || TARGET_THUMB1)
+return default_atomic_assign_expand_fenv (hold, clear, update);
You don't need to call default function here. It is empty, the
diff --git a/gcc/testsuite/gcc.dg/vect/vect-109.c
b/gcc/testsuite/gcc.dg/vect/vect-109.c
index 854c970..fb87e2c 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-109.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-109.c
@@ -1,4 +1,4 @@
-/* { dg-require-effective-target vect_int } */
+/* {
On Tue, Jul 29, 2014 at 10:19 AM, Jiong Wang jiong.w...@arm.com wrote:
the patch athttps://gcc.gnu.org/ml/gcc-patches/2014-07/msg00961.html
actually has one glitch on if check.
thumb target is code size sensitive, the best solution is we set
prefer_callee_reg_p to
true if we know that
On 11/11/14 08:40, Terry Guo wrote:
Hi there,
Attached patch intends to fix below trunk failure caused by recent thumb-1
UAL patch:
/tmp/cc9EfnXy.s: Assembler messages:
/tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not
permitted on this architecture -- `mov r6,r7'
Now for
On 12/11/14 13:06, Christophe Lyon wrote:
On 12 November 2014 04:50, Yangfei (Felix) felix.y...@huawei.com wrote:
On Wed, Oct 22, 2014 at 10:49 PM, Michael Collison michael.colli...@linaro.org
wrote:
Patch that removes extraneous comment attached.
The CLZ_DEFINED_VALUE_AT_ZERO macro is
On 07/11/14 13:36, Richard Henderson wrote:
On 11/07/2014 01:02 PM, Ramana Radhakrishnan wrote:
+ *cost = COSTS_N_INSNS (aarch64_internal_mov_immediate
+(gen_rtx_REG (mode, 0), x, false));
}
Can't you pass NULL for the register when generate
and resubmit if folks think this is a good idea.
regards
Ramana
2014-11-12 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* lib/wrapper.exp ${tool}_wrap_filename (): Define
* lib/g++.exp (g++_init): Use appropriate filename
for wrapper file.
* lib/gcc.exp (gcc_init
.
This is also in line with what we do in the AArch64 backend.
Will apply after a test run tonight on armhf.
regards
Ramana
* config/arm/sync.md (memory_barrier): Use dmb ish.
commit fca60730dee3281db4b688d9029ef08688507843
Author: Ramana Radhakrishnan ramana.radhakrish...@arm.com
Date: Fri Sep
the
recognizer kicks in.
Bootstrapped and regression tested on armhf.
Applied to trunk.
Ramana
2014-11-12 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* config/arm/arm.md (arith_shift_insn): Fix typo in operand
number.
Index: gcc/config/arm/arm.h
On Fri, Nov 14, 2014 at 11:11 AM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 14 November 2014 10:50, James Greenhalgh james.greenha...@arm.com wrote:
On Fri, Nov 14, 2014 at 10:42:27AM +, Andrew Pinski wrote:
On Fri, Nov 14, 2014 at 2:35 AM, James Greenhalgh
On 14/11/14 10:02, Terry Guo wrote:
Hi there,
Attached patch intends to fix a pattern that is found still non-UAL when do
gcc thumb-1 bootstrap. A test case is reduced and attached. Tested with gcc
regression test on pre-v6 thumb1 and v6 thumb1. No regression. Multilib can
be built for both
On Wed, Nov 12, 2014 at 9:51 AM, Terry Guo terry@arm.com wrote:
Hi there,
Attached patch intends to add pipeline description for ARM MCU Cortex-M7.
Is it ok to trunk?
This is OK. Can you please make sure there's an entry in changes for 5.0 ?
Ramana
BR,
Terry
2014-11-12 Terry Guo
On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
inappropriate.
Tested aarch64-none-elf. Reminder that at the moment
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch. Assuming no issue pops up,
OK for trunk?
On Wed, Nov 12, 2014 at 4:38 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This is a much-delayed respin of the patch in response to Richards feedback
at:
http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00068.html
We now let recursion do its magic and just add the cost of the
On Wed, Nov 12, 2014 at 5:08 PM, James Greenhalgh
james.greenha...@arm.com wrote:
Hi,
I was taking a look at fixing the issues in the ARM back-end exposed
by Marc Glisse's patch in [1], and hoped to fix them by adapting the
patch recently commited by Tejas ([2]).
As I looked, I realised
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
As part of some wider cleanup I'd like to do to ARM's Neon Builtin
infrastructure, my first step will be to remove the Magic Words used
to decide which variant of an instruction should be emitted.
The Magic Words interface allows a single
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
If we want to move all the code relating to builtin initialisation and
expansion to a common file, we must share the processor flags with that
common file.
This patch pulls those definitions out to config/arm/arm-protos.h
Bootstrapped and
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
The config/arm/arm.c file has always seemed a worrying size to me.
This patch pulls out the builtin related code to its own file. I think
this will be a good idea as we move forward. It seems a more sensible
separation of concerns. There are no
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
These macros can always be defined as a base case of VAR1 and a recursive
case of VARn-1. At the moment, the body of VAR1 is duplicated to each
macro.
This patch makes that change.
Regression tested on arm-none-linux-gnueabihf with no issues.
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
Now we have everything we need to start keeping track of the correct
qualifiers for each Neon builtin class in the arm back-end.
Some of the ARM Neon itypes are redundant when mapped to the qualifiers
framework. For now, don't change these, we
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
The poly types end up going through the default mangler, but only
sometimes.
We don't want to change the mangling for poly types with the next patch in
this series, so add a test which should pass before and after.
I've checked that the new
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
This patch wires up builtin initialisation similar to the AArch64 backend,
making use of the qualifiers arrays to decide on types for each builtin
we hope to initialise.
We could take an old snapshot of the qualifiers code from AArch64, but as
On 12/11/14 17:10, James Greenhalgh wrote:
Hi,
This final patch clears up the remaining data structures which we no
longer have any use for...
* _QUALIFIERS macros which do not name a distinct pattern of
arguments/return types.
* The neon_builtin_type_mode enum is not needed, we can
On Mon, Nov 17, 2014 at 5:06 AM, Hale Wang hale.w...@arm.com wrote:
Hi,
Refer to the previous small multiply patch (r217175).
The conditions in the small multiply test cases are not restrictive enough.
If forcing the march=armv4t/armv5t, these cases will fail.
These cases can be used only
On Mon, Nov 10, 2014 at 3:02 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
On 30 October 2014 23:02, Christophe Lyon christophe.l...@linaro.org wrote:
On 29 October 2014 16:28, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
On Thu, Nov 13, 2014 at 9:42 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
Following the trend in i386 and alpha, this patch uses std::swap to perform
swapping of values in the arm backend instead of declaring temporaries.
Tested and bootstrapped on arm-none-linux-gnueabihf.
Ok
On 18/11/14 11:02, Yangfei (Felix) wrote:
On 06/11/14 08:35, Yangfei (Felix) wrote:
The idea is simple: Use movw for certain const source operand
instead of
ldrh. And exclude the const values which cannot be handled by
mov/mvn/movw.
I am doing regression test for this patch.
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Ping? I hope this patch can catch up with stage 1 of GCC-5.0. Thanks.
Hi Felix,
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1], HImode))
#define TARGET_ARM (!
On 18/11/14 12:51, Yangfei (Felix) wrote:
On Tue, Nov 18, 2014 at 11:51 AM, Yangfei (Felix) felix.y...@huawei.com
wrote:
Ping again? Any comment please?
Pinging daily is only going to irritate people. Please desist from doing so.
Ramana
Oh, thanks for reminding me. And sorry if this
On Mon, Nov 17, 2014 at 5:13 PM, Marcus Shawcroft
marcus.shawcr...@gmail.com wrote:
On 14 November 2014 14:35, Wilco Dijkstra wdijk...@arm.com wrote:
2014-11-14 Wilco Dijkstra wdijk...@arm.com
* gcc/config/aarch64/aarch64.c (generic_regmove_cost):
Increase FP move cost.
On Tue, Nov 11, 2014 at 11:59 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This patch models the latency of moves between FP and GP registers on the
A15 and A57 a bit more accurately by splitting the reservations for FP-GP
and GP-FP moves and adding an appropriate bypass.
On 14/11/14 15:12, Maxim Kuvyrkov wrote:
On Nov 14, 2014, at 8:38 AM, Jeff Law l...@redhat.com wrote:
On 10/20/14 22:06, Maxim Kuvyrkov wrote:
Hi,
Ramana, this change requires benchmarking, which I can't easily do
at
the moment. I would appreciate any benchmarking results that you can
On 19/11/14 09:29, Yangfei (Felix) wrote:
Sorry for missing the point. It seems to me that 't2' here will conflict with
condition of the pattern *movhi_insn_arch4:
TARGET_ARM
arm_arch4
(register_operand (operands[0], HImode)
|| register_operand (operands[1],
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com wrote:
I think I missed the stage3, Anyway would it be OK for stage1 when it
reopens ?
Since you submitted this well during stage1 and given that these
patches address comments from earlier in the review process we should
A testcase is added for all targets as I think it's a middle-end
issue. And sorry for not being able to simplify it.
arm-none-eabi has been test on the model, no new issues. bootstrapping
and regression tested on x86, no new issues.
Is it Okay to commit?
Yes. Thanks very much for working on
?
regards
Ramana
2014-11-20 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/59593
* config/arm/arm.md (*movhi_insn): Use right formatting
for immediate.
Index: gcc/ChangeLog
===
--- gcc
On Wed, Nov 19, 2014 at 9:42 PM, Philipp Tomsich
philipp.toms...@theobroma-systems.com wrote:
Here's an updated patch with Kyrill's and Andrew's comments integrated.
I left the file in the config/arm-directory, as XGene-family is capable of
executing ARMv7 and we will wire this into the 32bit
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This patch adds support for the Cortex-A17 processor to the arm backend.
Cortex-A17 is an ARMv7ve core with the same architectural features as the
Cortex-A7, A12 and A15 cores.
The -m{tune, cpu}=cortex-a17
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
The Cortex-A12 very close to the Cortex-A17 and this patch updates the
tuning struct
parameters to match the Cortex-A17 ones.
This has improved performance in a number of benchmarks that I tried.
The
5:33 PM
To: Thomas Preud'homme
Cc: Tony Wang; gcc-patches@gcc.gnu.org; d...@debian.org; aph-
g...@littlepinkcloud.com; Richard Earnshaw; Ramana Radhakrishnan;
libstd...@gcc.gnu.org
Subject: Re: [Patch, ARM, ping1] Fix PR target/56846
On 26/11/14 17:23 -, Thomas Preud'homme wrote:
Ping?
I'm
On Thu, Nov 13, 2014 at 4:03 PM, Thomas Preud'homme
thomas.preudho...@arm.com wrote:
[Taking over Tony's patch]
Ping?
Best regards,
Thomas
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Tony Wang
Sent: Thursday,
, 2014 3:31 PM
To: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw
Subject: [PATCH][ARM] Fix PR59593/PR63742: arm *movhi_insn_arch4
pattern for big-endian
Currently, constant pool entries for QImode, HImode and SImode values
are filled as 32-bit quantities. This works fine
On Tue, Nov 18, 2014 at 10:40 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
Following up from adding Cortex-A17 support this patch adds a big.LITTLE
option cortex-a17.cortex-a7.
Similar to the existing cortex-a15.cortex-a7 support we schedule for
Cortex-A7 and make the other
On Wed, Oct 29, 2014 at 10:20 AM, Jiong Wang jiong.w...@arm.com wrote:
On 26/08/14 13:36, Richard Earnshaw wrote:
On 29/07/14 15:49, Jiong Wang wrote:
test done
===
no regression on the full toolchain test on arm-none-eabi.
ok to install?
Hmm, I think this is wrong for DF mode. The
On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel christian.br...@st.com wrote:
On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote:
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel christian.br...@st.com
wrote:
I think I missed the stage3, Anyway would it be OK for stage1 when it
reopens
On 27/11/14 11:09, Kyrill Tkachov wrote:
On 27/11/14 08:52, Ramana Radhakrishnan wrote:
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This patch adds support for the Cortex-A17 processor to the arm backend.
Cortex-A17 is an ARMv7ve core with the same
intend to backport the same to the 4.9 branch as the issue exists there
too and this is just in the configury and build of the baremetal toolchain.
regards
Ramana
2014-11-28 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* config/arm/t-aprofile (MULTILIB_MATCHES): New entry
On Wed, Sep 24, 2014 at 6:17 AM, Terry Guo terry@arm.com wrote:
Hi there,
The attached patch intends to provide option support to newly announced core
Cortex-M7 and related FPU:
http://www.arm.com/about/newsroom/arm-supercharges-mcu-market-with-high-perf
ormance-cortex-m7-processor.php
On Wed, Oct 1, 2014 at 10:03 AM, Christian Bruel christian.br...@st.com wrote:
Hi Ramana,
Your patch https://gcc.gnu.org/ml/gcc-patches/2012-02/msg01492.html
seems to have not been applied for 4.10. Are there any stoppers or is it
an omission ?
Short answer, no, not an omission. It could
Hi,
I've been digging into why on AArch64 we generate pretty bad code
for the following testcase.
void g2(float, float, float, float, float, float, float, float);
void f2a(void)
{
float x0 = 1.0, x1 = 2.0, x2 = 3.0, x3 = 4.0, x4 = 5.0, x5 = 6.0, x6
= 7.0, x7 = 8.0;
float x8 = 0.5,
If the port has a splitter to rip apart a douple-word load into single-word
loads, then we'd obviously only want to do that in cases where the
double-word load actually generates 1 assembly instruction.
Or indeed if it is really a performance win. And I think that should
purely be a per
What do you prefer me to do for these tests? I can think of:
- do not include them at all until fp16 is fully supported on both
AArch32 and AArch64
- include only those with float16x4_t
- include both float16x4_t and float16x8_t tests, leaving float16x8_t commented
I would include them both
Hi Christian,
Thanks for looking at this. I will need to read the code in detail but
this is a first top level reivew.
On 09/29/14 12:03, Christian Bruel wrote:
Hi Ramana, Richard,
This patch implements the attribute target (and pragma) to allow
function based interworking.
as in the
arrives with the
different parts.
regards
Ramana
Best Regards
Christian
On 10/08/2014 03:05 PM, Ramana Radhakrishnan wrote:
Hi Christian,
Thanks for looking at this. I will need to read the code in detail but
this is a first top level reivew.
On 09/29/14 12:03, Christian Bruel
On 16/10/14 21:43, Andrew Pinski wrote:
On Thu, Oct 16, 2014 at 1:38 PM, Sebastian Pop seb...@gmail.com wrote:
Richard Biener wrote:
I have posted 5 patches as part of a larger series to merge
(parts) from the match-and-simplify branch. While I think
there was overall consensus that the
On Wed, Oct 15, 2014 at 5:29 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
On 15/10/14 14:00, Richard Biener wrote:
Any comments and reviews welcome (I don't think that
my maintainership covers enough to simply check this in
without approval).
Hi Richard,
The match-and-simplify
On Mon, Oct 20, 2014 at 10:17 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Maxim Kuvyrkov maxim.kuvyr...@linaro.org writes:
[Adding ARM maintainers to CC]
On Oct 21, 2014, at 9:44 AM, Sebastian Pop seb...@gmail.com wrote:
Hi Maxim,
Maxim Kuvyrkov wrote:
Thanks, benchmarking
...@redhat.com
Ramana Radhakrishnan ramana.radhakrish...@arm.com
* dwarf2out.c (const_ok_for_output_1): Reject expressions containing a
NOT.
gcc/testsuite
DATE Ramana Radhakrishnan ramana.radhakrish...@arm.com
* gcc.c-torture/compile/pr60655-1.c: New test.
commit
and verified that the correct multilibs are now chosen.
Applied to trunk as nearly obvious.
regards,
Ramana
2014-03-28 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* config/arm/t-aprofile (MULTILIB_MATCHES): Correct A12 rule.
Index: gcc/config/arm/t-aprofile
On Tue, Mar 25, 2014 at 3:51 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This two-patch series adds scheduling information for the ARMv8-A Crypto
instructions on the Cortex-A53.
This first patch does some preliminary restructuring to allow the arm and
aarch64 backends to share
On Fri, Mar 28, 2014 at 5:18 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
On 28/03/14 14:18, Ramana Radhakrishnan wrote:
On Tue, Mar 25, 2014 at 3:51 PM, Kyrill Tkachov kyrylo.tkac...@arm.com
wrote:
Hi all,
This two-patch series adds scheduling information for the ARMv8-A Crypto
On Wed, Mar 19, 2014 at 9:55 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
In order to properly cost the rev16 instruction we need a new field in the
cost tables.
This patch adds that and specifies its value for the existing cost tables.
Since rev16 is used to implement the BSWAP
On Wed, Mar 19, 2014 at 9:56 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This is the arm equivalent of patch [2/3] in the series that adds combine
patterns for the bitwise operations leading to a rev16 instruction.
It reuses the functions that were put in aarch-common.c to
On Wed, Mar 19, 2014 at 9:55 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
This patch adds a recogniser for the bitmask,shift,orr sequence of
instructions that can be used to reverse the bytes in 16-bit halfwords (for
the sequence itself look at the testcase included in the patch).
On Tue, Mar 25, 2014 at 3:52 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
In ARMv8-A there's a general expectation that AESE/AESMC and AESD/AESIMC
sequences of the form:
AESE Vn, _
AESMC Vn, Vn
will issue both instructions in a single cycle on super-scalar
implementations. It
/gcc.target/arm/pr60650.c
...
+ asm (1\t.long );
This asm looks quite bogus, and with
asm ();
it ICEs the same way, can it be changed?
+ __builtin_unreachable ();
+}
+}
Jakub
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.diff --git a/gcc/testsuite
On Thu, Apr 3, 2014 at 2:27 PM, Charles Baylis
charles.bay...@linaro.org wrote:
Hi
This bug causes the compiler to create a Thumb-2 TBB instruction with
a jump table containing an out of range value in a .byte field:
whatever.s:148: Error: value of 256 too large for field of 1 bytes at 100
On Thu, Apr 3, 2014 at 9:22 PM, Jeff Law l...@redhat.com wrote:
As noted in the PR, there are a few insns in the ARM backend which use
const_int_operand as a predicate, but which have constraints like I or
M.
With the predicate accepting all constants, it's possible for a pass such as
On Thu, Mar 27, 2014 at 11:25 AM, Ramana Radhakrishnan ramra...@arm.com wrote:
Hi,
This is a partial fix for PR60655 where dwarf2out.c rejects NOT of a
value in const_ok_for_output_1. There is still a problem with the testcase
on armhf where we get operations of the form, const (minus
My first reaction is to wonder why this is this not a bug in the
shorten phase.
I don't think that code ever expected an alignment directive to be emitted
by ASM_OUTPUT_CASE_END :(
Fair point and it looks like this support came in when the support for
Thumb2 was added eons ago.
This
On Fri, Apr 4, 2014 at 1:35 PM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
Hi all,
In PR 60743 it is noted that the genautomata computation has increased a lot
in both size and time due to my recently added a53 scheduling additions.
This patch attempts to mitigate that by reducing the large
As subject says.
Applied as obvious.
Ramana
2014-04-07 Ramana Radhakrishnan ramana.radhakrish...@arm.com
* gcc.target/arm/pr60657.c: Fix missing curly brace.
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.Index: gcc/testsuite/ChangeLog
Sorry about the delayed review. I seem to have missed this earlier.
On Tue, Mar 25, 2014 at 12:21 PM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
because of popular demand we switched the Ada compiler to ZCX, i.e. table-
driven EH scheme, on ARM/Linux, only to discover that GCC doesn't
,
Merzlyakov Alexey
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.
distro configuration - testing came back clean.
Applied to trunk.
regards
Ramana
2014-04-10 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR debug/60655
* config/arm/arm.c (TARGET_CONST_NOT_OK_FOR_DEBUG_P): Define
(arm_const_not_ok_for_debug_p): Reject MINUS
4.9 changes for ARM / AArch64. Sorry it's taken me a while to get this
out but better late than never :)
Ok ?
Ramana
--
Ramana Radhakrishnan
Principal Engineer
ARM Ltd.Index: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc
1 - 100 of 1347 matches
Mail list logo
