On Mon, Jul 4, 2016 at 3:14 PM, Matthew Wahab
wrote:
> On 17/05/16 15:44, Matthew Wahab wrote:
>> The ARMv8.2-A architecture introduces an optional FP16 extension adding
>> half-precision floating point data processing instructions to the
>> existing scalar (floating point) support. A future versi
> appear UNSUPPORTED.
> That's because this config appears to define
> __ARM_ARCH_EXT_IDIV__ however idiv appears not to be present.
>
> For instance __aeabi_div is called to perform
> division for the following test-case:
> int f(int x, int y)
> {
> int r = x / y;
> return r;
> }
>
> Compil
On Sun, Nov 6, 2016 at 2:18 PM, Bernd Edlinger
wrote:
> Hi!
>
> This improves the stack usage on the sha512 test case for the case
> without hardware fpu and without iwmmxt by splitting all di-mode
> patterns right while expanding which is similar to what the shift-pattern
> does. It does nothing
On Wed, Nov 16, 2016 at 4:57 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> As the PR says we have an RTL checking failure that occurs when building
> libgcc for aarch64.
> The expander code for addsi3 takes the REGNO of a SUBREG in operands[1]. The
> three operands
> in the failing case are:
> {(reg:SI
On Wed, Nov 30, 2016 at 11:48 AM, Thomas Preudhomme
wrote:
> Hi,
>
> With ARM Cortex-M23 and Cortex-M33 and the support for RM profile multilib
> added recently, it's time to add the corresponding CPU to architecture
> mappings in config/arm/t-rmprofile. Note that Cortex-M33 is mapped to
> ARMv8-M
On Fri, Dec 9, 2016 at 3:58 PM, Bernd Schmidt wrote:
> On 12/09/2016 04:34 PM, Andre Vieira (lists) wrote:
>
>> Regardless, the other testcases I add in this patch show a sub-optimal
>> transformation done by postreload, turning direct calls into indirect
>> calls, for targets which have specifica
On Wed, Dec 14, 2016 at 5:43 PM, Wilco Dijkstra wrote:
> Kyrill Tkachov wrote:
>> On 14/12/16 16:37, Wilco Dijkstra wrote:
>>
>> > Merge the movdi_vfp_cortexa8 pattern into movdi_vfp and remove it to avoid
>> > unnecessary duplication and repeating bugs like PR78439 due to changes
>> > being
>> >
On 09/12/16 14:03, Kyrill Tkachov wrote:
Hi all,
In this ICE GCC reports invalid RTL sharing in the pattern:
(insn 955 954 956 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("a") [flags 0xe8] )
(const_int 4 [0x4])
>
> Ping? Note that the patch has been on GCC 6 for more than 3 months now without
> any issue reported against it.
OK.
Ramana
>
> Best regards,
>
> Thomas
On Thu, Apr 28, 2016 at 10:24 AM, Kyrill Tkachov
wrote:
>
> On 21/03/16 10:41, Ramana Radhakrishnan wrote:
>>
>> On Fri, Mar 11, 2016 at 3:32 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> As reported in the PR we can end
On 04/05/16 11:26, Eric Botcazou wrote:
>> Given how many latent bugs it has shown up I think that alone would make
>> it valuable to have enabled at -O2.
>
> It might be worthwhile to test it on embedded architectures because modern
> x86
> and PowerPC processors are probably not very sensiti
On Wed, May 4, 2016 at 2:37 PM, Bernd Schmidt wrote:
> On 05/04/2016 03:25 PM, Ramana Radhakrishnan wrote:
>>
>> On ARM / AArch32 I haven't seen any performance data yet - the one
>> place we are concerned about the impact is on Thumb2 code size as
>> regrename
On Wed, May 4, 2016 at 4:20 PM, Wilco Dijkstra wrote:
> Bernd Schmidt wrote:
>> On 05/04/2016 03:25 PM, Ramana Radhakrishnan wrote:
>>> On ARM / AArch32 I haven't seen any performance data yet - the one place we
>>> are concerned
>>> about the impact is
On Thu, Mar 31, 2016 at 2:11 PM, Ramana Radhakrishnan
wrote:
> Hi,
>
> In this PR we have a situation where we aren't really detecting
> weak references vs weak definitions. If one has a weak definition
> that binds locally there's no reason not to put out
On Tue, May 10, 2016 at 2:02 PM, Christophe Lyon
wrote:
> On 9 May 2016 at 15:34, Christophe Lyon wrote:
>> On 9 May 2016 at 15:29, Jeff Law wrote:
>>> On 05/09/2016 01:37 AM, Christophe Lyon wrote:
>>>
Hi,
After this merge, I'm seeing lots of timeouts on arm (using QEMU).
Is
>
> I've looked at the generated code in more details, and for armv6 this
> generates
> mcr p15, 0, r0, c7, c10, 5
> which is not what __cilkrts_fence uses currently (CP15DSB vs CP15DMB)
Wow I hadn't noticed that it was a DSB - DSB is way too heavy weight. Userland
shouldn't need to use
On 10/05/16 19:20, Bernd Schmidt wrote:
> On 05/10/2016 08:05 PM, Richard Biener wrote:
>> On May 10, 2016 7:02:33 PM GMT+02:00, Jeff Law
>> wrote:
>>> Well, not if we take Bernd's idea and create a new backend for
>>> testing purposes. If we want to know/test what reload's doing, we
>>> cons u
On Thu, May 5, 2016 at 12:50 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> In this PR we deal with some fallout from the conversion to unified
> assembly.
> We now end up emitting instructions like:
> pop {r0,r1,r2,r3,pc}^
> which is not legal. We have to use an LDM form.
>
> There are bugs in two arm
27;s the subject of a separate patch.
regards
Ramana
>
> gcc/
> 2016-04-27 Matthew Wahab
> Ramana Radhakrishnan
> Jiong Wang
>
> * config/arm/arm-c.c (arm_cpu_builtins): Use def_or_undef_macro
> for __ARM_FP16_FORMAT_IEEE
On Tue, May 17, 2016 at 1:22 AM, Sandra Loosemore
wrote:
> On 05/16/2016 04:35 PM, Jim Wilson wrote:
>>
>> This is my fifth ping. I just need someone to rubber stamp it so I
>> can check it in.
>
>
> The documentation change looks fine, but as a documentation maintainer only
> I don't think I can
On Tue, May 17, 2016 at 1:25 PM, Christophe Lyon
wrote:
> On 1 April 2016 at 17:32, Ramana Radhakrishnan
> wrote:
>> I've had this in my tree for a few months now but never got
>> around to submitting it.
>>
>> This partially fixes PR target/53440 atleast in
On Mon, May 16, 2016 at 2:16 PM, Tejas Belagod
wrote:
>
> We do have plans to fix pre-ACLE behavior of fp16 to conform to current ACLE
> spec, but can't say when exactly.
Matthew, could you please take a look at this while you are in this area ?
thanks,
Ramana
>
> Thanks,
> Tejas.
On 18/05/16 15:33, Matthew Wahab wrote:
> On 18/05/16 09:41, Ramana Radhakrishnan wrote:
>> On Mon, May 16, 2016 at 2:16 PM, Tejas Belagod
>> wrote:
>>
>>>
>>> We do have plans to fix pre-ACLE behavior of fp16 to conform to current ACLE
>>> spec,
On 11/05/16 15:32, Kyrill Tkachov wrote:
> Hi all,
>
> In this PR a NEON builtin is introduced during SLP vectorisation even when
> NEON is not available
> because arm_builtin_vectorized_function is missing an appropriate check in
> the BSWAP handling code.
>
> Then during expand when we try to
On 27/04/16 15:13, Kyrill Tkachov wrote:
> Hi all,
>
> Another costs issue that came out of the investigation for PR 65932 is that
> sign-extending loads get a higher cost than they should in the arm backend.
> The problem is that when handling a sign-extend of a MEM we add the cost
> of the load_
Hi,
The Steering Committee has decided to add aarch64-none-linux-gnu as a primary
platform for GCC-7. This reflects the increasing popularity of the port and the
increased general availability of hardware. I also took the opportunity of
creating a GCC-7 criteria page at the same time.
Applied.
On 24/05/16 09:52, Kyrill Tkachov wrote:
> Hi all,
>
> As the PR says, the gen_operands_ldrd_strd function has a spurious return
> false in it.
> It seems to have been there from the beginning when that code was added.
>
> The code is trying to transform:
> mov r0, 0
> str r0,
On Mon, Aug 10, 2015 at 11:28:06AM +0100, Matthew Wahab wrote:
> Ping. Updated patch attached.
>
> Also, retested the series for arm-none-linux-gnueabihf with native
> bootstrap and make check.
>
> On 22/06/15 16:16, Matthew Wahab wrote:
> >Hello,
> >
> >The ARM backend records FPU features as bo
On Mon, Jun 22, 2015 at 04:18:04PM +0100, Matthew Wahab wrote:
> Hello,
>
> This patch series changes the representation of FPU features to use a simple
> bit-set and flags, as is done elsewhere.
>
> This patch uses the new representation of FPU feature sets.
>
> Tested the series for arm-none-l
On Mon, Aug 10, 2015 at 12:56:59PM +0100, Matthew Wahab wrote:
> The ARM backend uses an unsigned long to record CPU feature flags and
> there are currently 31 bits in use. This series of patches replaces the
> single unsigned long with a representation based on an array of values.
>
> This patch
On Mon, Aug 10, 2015 at 12:55:45PM +0100, Matthew Wahab wrote:
> The ARM backend uses an unsigned long to record CPU feature flags and
> there are wcurrently 31 bits in use. To be able to support new
> architecture features, the current representation will need to be
> replaced so that more flags c
>
> Yes in big-endian DI mode value are stored into VFP registers, and
> here register 16 is the first of them s0. Just in case you want to do
> more test, the issue can be seen with a oneline testcase:
>
> __attribute__((__vector_size__(2 * sizeof(int int fn1() {}
Yep we may well have DImo
On 14/08/15 10:23, James Greenhalgh wrote:
>
> Hi,
>
> I spotted that these are missing from the "is_neon_type" attribute:
>
> neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,
> neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,
> neon_fp_to_int_d,
On Mon, Aug 10, 2015 at 12:57 PM, Matthew Wahab
wrote:
> The ARM backend uses an unsigned long to record CPU feature flags and
> there are currently 31 bits in use. This series of patches replaces the
> single unsigned long with a representation based on an array of values.
>
> This patch replaces
On Mon, Aug 10, 2015 at 12:58 PM, Matthew Wahab
wrote:
> The ARM backend uses an unsigned long to record CPU feature flags and
> there are currently 31 bits in use. This series of patches replaces the
> single unsigned long with a representation based on an array of values.
>
> This patch updates
On Mon, Aug 10, 2015 at 1:00 PM, Matthew Wahab
wrote:
> The ARM backend uses an unsigned long to record CPU feature flags and
> there are currently 30 bits in use. This series of patches replaces the
> single unsigned long with a representation based on an array of values.
>
> This patch updates t
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300)
> spawn
> Hi Marcus,
>
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeou
On 18/08/15 08:53, Michael Collison wrote:
>
> This patch is designed to address code that was not being vectorized due to
> missing widening patterns in the ARM backend. Code such as:
>
> int t6(int len, void * dummy, short * __restrict x)
> {
> len = len & ~31;
> int result = 0;
> __as
On 14/08/15 10:56, Kyrill Tkachov wrote:
> Hi all,
>
> I'm seeing these warnings when building arm.c:
> warning: format ‘%lld’ expects argument of type ‘long long int’, but argument
> 5 has type ‘long int’ [-Wformat=]
>
> These appear in the bounds_check function when it tries to print out
>
ite/gcc.target/arm/neon-vaddwu16.c
> b/gcc/testsuite/gcc.target/arm/neon-vaddwu16.c
> new file mode 100644
> index 000..98f8768
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/neon-vaddwu16.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-require-eff
>
> I have tested that, arm-none-linux-gnueabi bootstraps Okay on trunk code.
JFTR, this is ok to backport to gcc-5 in case there are no regressions.
regards
Ramana
>
>>
>> Thanks,
>> Kyrill
>>
>>
>
On Mon, Sep 7, 2015 at 9:35 AM, Charles Baylis
wrote:
> On 2 September 2015 at 13:09, Jan Hubicka wrote:
>> It kind of sucks that one needs to mind this flag each time one creates edge,
>> but setting the value in create_edge is not quite correct as that one does
>> not
>> have any information o
On 24/07/15 11:55, Kyrill Tkachov wrote:
>
> commit d562629e36ba013b8f77956a74139330d191bc30
> Author: Kyrylo Tkachov
> Date: Fri Jul 17 16:30:01 2015 +0100
>
> [ARM][3/3] Expand mod by power of 2
>
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index e1bc727..6ade07c 1006
On Thu, Jul 23, 2015 at 12:15 PM, Alex Velenko wrote:
> Hi,
>
> This patch prevents testcase pr63210.c from running with -march=armv4t.
> Object size check should be skipped with explicit -march=armv4t, because
> expected size is only correct using pop pc instruction which is unsafe for
> armv4t.
On 01/09/15 16:10, Kyrill Tkachov wrote:
> [Resending with patch attached]
>
> Hi all,
>
> This third patch implements the new optabs for arm.
> Conveniently, we can reuse the recently refactored *if_neg_move pattern
> and extend it to cover the conditional NOT case.
> Although arm has conditio
On Thu, Sep 10, 2015 at 10:03 AM, Kyrill Tkachov wrote:
> Hi all,
>
> The ICE in this PR occurs when trying to compile code containing
> half-precision FP operations
> for Thumb2 with -mrestrict-it and an -mfpu that does not support fp16
> (-mfpu=neon or lower).
>
> The problem is that we disable
On Thu, Aug 27, 2015 at 03:07:30PM +0100, Marcus Shawcroft wrote:
> On 27 July 2015 at 15:33, Ramana Radhakrishnan
> wrote:
>
> > Ramana Radhakrishnan
> >
> > PR target/63304
> > * config/aarch64/aarch64.c (aarc
On Fri, Sep 11, 2015 at 10:53:13AM +0200, Bernd Schmidt wrote:
> On 09/10/2015 11:11 PM, Jeff Law wrote:
> >I think that's probably what James is most interested in getting some
> >ideas around -- the cost model.
> >
> >I think the fundamental problem is BRANCH_COST isn't actually relative
> >to an
On Fri, Sep 11, 2015 at 2:19 PM, Bill Schmidt
wrote:
> Hi Alan,
>
> I probably wasn't clear enough. The implementation in the vectorizer is
> fine and I'm not asking that to change per target. What I'm objecting
> to is the equivalence between a REDUC_MAX_EXPR and a cost associated
> with vec_to
>>> Saying that all reductions have equivalent performance is unlikely to be
>>> true for many platforms. On PowerPC, for example, a PLUS reduction has
>>> very different cost from a MAX reduction. If the model isn't
>>> fine-grained enough, let's please be aggressive about fixing it. I'm
>>> f
On 27/08/15 15:07, Marcus Shawcroft wrote:
> On 27 July 2015 at 15:33, Ramana Radhakrishnan
> wrote:
>
>> Ramana Radhakrishnan
>>
>> PR target/63304
>> * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Handle
>
On Thu, Nov 3, 2016 at 12:20 PM, Wilco Dijkstra wrote:
> Fix ldrd offsets of Thumb-2 - for TARGET_LDRD the range is +-1020,
> without -255..4091. This reduces the number of addressing instructions
> when using DI mode operations (such as in PR77308).
>
> Bootstrap & regress OK.
>
> ChangeLog:
> 2
On Thu, Oct 6, 2016 at 2:57 PM, Andre Vieira (lists)
wrote:
> Hello,
>
> This patch tackles the issue reported in PR71607. This patch takes a
> different approach for disabling the creation of literal pools. Instead
> of disabling the patterns that would normally transform the rtl into
> actual li
On Tue, Nov 22, 2016 at 9:57 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> This PR is an ICE while bootstrapping GCC with Cortex-A8 tuning, which we
> also get from the default ARMv7-A tuning.
> The ldrd/strd peepholes were recently made more aggressive and in this case
> they transform:
> (insn 13 33 4
On Thu, Oct 13, 2016 at 4:35 PM, Thomas Preudhomme
wrote:
> Hi ARM maintainers,
>
> This patchset aims at adding multilib support for R and M profile ARM
> architectures and allowing it to be built alongside multilib for A profile
> ARM architectures. This specific patch adds the t-rmprofile multi
On Tue, Nov 22, 2016 at 9:57 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> This PR is an ICE while bootstrapping GCC with Cortex-A8 tuning, which we
> also get from the default ARMv7-A tuning.
> The ldrd/strd peepholes were recently made more aggressive and in this case
> they transform:
> (insn 13 33 4
On Tue, Dec 15, 2015 at 4:07 PM, Matthew Wahab
wrote:
> On 10/12/15 10:49, Ramana Radhakrishnan wrote:
>>
>> On Mon, Dec 7, 2015 at 4:10 PM, Matthew Wahab
>> wrote:
>>>
>>> On 27/11/15 17:11, Matthew Wahab wrote:
>>>>
>>>> On 27/11/1
On Tue, Dec 15, 2015 at 4:03 PM, Matthew Wahab
wrote:
> On 10/12/15 10:45, Ramana Radhakrishnan wrote:
>>
>> On Tue, Dec 8, 2015 at 7:45 AM, Christian Bruel
>> wrote:
>>>
>>> Hi Matthew,
>>>>
>>>>
>>>> On 26/11/15 16:01
>>
>> I couldn't find 0/7 but in addition here you need to update the output
>> for TAG_FP_SIMD_Arch to be 4.
>>
>> regards
>> Ramana
>
> After discussing this offline, it turns out that the relevant attribute
> (Tag_Advanced_SIMD_arch) is set by the assembler.
Yep - sorry about the noise.
The
On Wed, Dec 16, 2015 at 9:11 AM, Thomas Preud'homme
wrote:
> During reorg pass, thumb1_reorg () is tasked with rewriting mov rd, rn to
> subs rd, rn, 0 to avoid a comparison against 0 instruction before doing a
> conditional branch based on it. The actual avoiding of cmp is done in
> cbranchsi4
On Thu, Nov 12, 2015 at 3:16 PM, Andre Vieira
wrote:
> On 12/11/15 15:08, Andre Vieira wrote:
>>
>> Hi,
>>
>>This patch changes the memset-inline-10.c testcase to make sure that
>> it is only compiled for ARM targets that support -mfloat-abi=hard using
>> the fact that all non-thumb1 targets d
On Fri, Jan 15, 2016 at 3:05 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> In this PR the ARMv8 vcvt instructions end up being conditionalised when
> they don't have a conditional form.
> setting the predicable attribute to "no" is not enough. We need to set the
> "conds" attribute to unconditional as w
On Mon, Dec 8, 2014 at 11:24 AM, Bernd Edlinger
wrote:
> Hi Kyrill,
>
>
>> Hi all,
>>
>> As the subject says, this just fixes a typo in the fprofile-generate
>> option name and rewords the text in the next sentence a bit.
>> Ok to commit?
>>
>> Thanks,
>> Kyrill
>
>
>
> I think this kind of change
On Tue, Sep 23, 2014 at 4:07 PM, Kyrill Tkachov wrote:
> Hi all,
>
> Some intrinsics had the wrong name (inconsistent with the NEON intrinsics
> spec). This patch fixes that and adds the vrndx_f32 and vrndxq_f32
> intrinsics that were missing.
> These map down to vrintx.f32 NEON instructions (d an
On Thu, Dec 11, 2014 at 9:34 AM, Kyrill Tkachov wrote:
> Hi all,
>
> While looking in this area on other business I noticed we could be using the
> names R0_REGNUM
> and R1_REGNUM when creating those REG rtxs since it's a bit more descriptive
> that just 0 and 1.
>
> Tested arm-none-eabi.
>
> Ok f
Sorry about the slow response- have been on holiday and still catching
up on email.
On 12/01/15 13:16, Andrew Stubbs wrote:
Ping.
On 23/12/14 16:46, Andrew Stubbs wrote:
On 03/12/14 15:03, Andrew Stubbs wrote:
The tools have always allowed us to drop down the arch to
march=armv5te along with
On Thu, Dec 4, 2014 at 9:19 AM, Kyrill Tkachov wrote:
>
> On 02/12/14 22:58, Ramana Radhakrishnan wrote:
>>
>> On Tue, Nov 11, 2014 at 11:55 AM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> This is the arm implementation of the
On 12/01/15 20:15, Philipp Tomsich wrote:
---
gcc/ChangeLog-2014| 10 ++
gcc/config/arm/arm-cores.def | 1 +
gcc/config/arm/arm-tables.opt | 3 +++
gcc/config/arm/arm-tune.md| 3 ++-
gcc/config/arm/arm.c | 22 ++
gcc/config/arm/arm
On 12/01/15 20:15, Philipp Tomsich wrote:
---
gcc/config/aarch64/aarch64.md | 2 +-
gcc/config/arm/types.md | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 1f6b1b6..98f4f30 100644
--- a/gcc/confi
On Sun, Jan 11, 2015 at 9:55 PM, Andreas Tobler wrote:
> Hi,
>
> I have here a possible way to make the enum_9.f90 and the enum_10.f90 work
> under arm*-*-freebsd*. The solution for enum_9.f90 is straight forward. But
> the one for enum_10.f90 requires a reordering of the dg-additional-sources
> l
On 19/11/14 02:43, Joey Ye wrote:
Current thumb2 -Os generates suboptimal code for following tail call case:
int f4(int b, int a, int c, int d);
int g(int a, int b, int c, int d)
{ return f4(b, a, c, d); }
arm-none-eabi-gcc -Os -mthumb -mcpu=cortex-m3 test.c
push
{r4, lr}
mov r4, r1
mov r1,
On Thu, Jan 8, 2015 at 8:51 PM, Andreas Tobler wrote:
> On 08.01.15 17:27, Richard Earnshaw wrote:
>>
>> On 29/12/14 18:44, Andreas Tobler wrote:
>>>
>>> All,
>>>
>>> here is the third attempt to support ARM with FreeBSD.
>>>
>>> In the meantime we found another issue in the unwinder where I had t
On 13/01/15 21:01, Andrew Stubbs wrote:
On 12/01/15 13:50, Ramana Radhakrishnan wrote:
In principle ok, but I'd like a comment in there explaining why we've
done this. Can you also post under what configurations these have been
tested ?
Is this better?
I tested it by running th
On Mon, Jan 12, 2015 at 2:29 PM, Kyrill Tkachov wrote:
> Now with patch attached
>
> Kyrill
>
>
> On 12/01/15 14:27, Kyrill Tkachov wrote:
>>
>> Hi all,
>>
>> In this PR we ICE when compiling with -mtune=xscale. The ICE is a
>> segfault in xscale_sched_adjust_cost.
>> The root cause is that xscale
On 14/01/15 10:14, Hale Wang wrote:
Hi,
This patch is tuned particularly for benchmark performance on cortex-m7.
Tested with GCC regression test, no regressions. Is it ok for trunk?
BR,
Hale Wang
gcc/ChangeLog
2014-12-24 Hale Wang
* config/arm/arm.c: Tune the max_cond_insns/branc
On Wed, Jan 14, 2015 at 10:20 AM, Thomas Preud'homme
wrote:
> When compiling for size, live high registers are not saved in function prolog
> in ARM backend in Thumb mode. The problem comes from
> arm_conditional_register_usage setting call_used_regs for all high register
> to avoid them being
the tests would fail without Patch 2/3 please don't add them.
Ramana
Best regards,
Thomas
-Original Message-
From: Richard Earnshaw
Sent: Wednesday, January 14, 2015 2:53 PM
To: Thomas Preud'homme; Tony Wang; gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan
Subject: Re: [PA
On 11/12/12 14:10, Ulrich Weigand wrote:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01521.html
Ping.
This is OK.
Please apply.
regards,
Ramana
On 13 Nov 2012, at 21:18, Konstantin Serebryany
wrote:
> On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
>> On Tue, Nov 13, 2012 at 12:07 AM, David Miller wrote:
>>>
>>> This has broken the build on every Linux target that hasn't added
>>> the necessary cpu specific code to asan_linux
On Tue, Nov 13, 2012 at 10:41 PM, Andrew Pinski wrote:
> On Tue, Nov 13, 2012 at 2:31 PM, Ramana Radhakrishnan
> wrote:
>>
>>
>> On 13 Nov 2012, at 21:18, Konstantin Serebryany
>> wrote:
>>
>>> On Tue, Nov 13, 2012 at 8:21 AM, Diego Novillo wrote:
r~
PS: ARM still uses sjlj exceptions for Ada? I thought with the obsolescence
of pre-eabi targets that we'd always use unwind tables now.
I believe this is by choice because no one has yet written an unwinder
for the ARM exception tables for Ada :( .
regards,
Ramana
On 11/15/12 20:05, Richard Henderson wrote:
On 11/15/2012 12:01 PM, Ramana Radhakrishnan wrote:
I believe this is by choice because no one has yet written an unwinder for the
ARM exception tables for Ada :( .
Ada is supposed to be using the same libgcc unwinder as the rest of
the compiler
On 11/19/12 17:51, Kyrylo Tkachov wrote:
Hi all,
This patch updates the arm_abssi2 and arm_neg_abssi2 patterns in the ARM
machine description.
We define the predicable attribute based on the alternative. When the
patterns were introduced it was not possible to do that.
Now the second alternative
On Wed, Nov 14, 2012 at 10:30 PM, Matthias Klose wrote:
> The following patch adds the multiarch definitions for arm-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
Ok.
Ramana
>
> Matthias
>
On Fri, Nov 16, 2012 at 5:37 AM, Bin Cheng wrote:
> Hi,
> This patch defines LOGICAL_OP_NON_SHORT_CIRCUIT for ARM target and prefers
> short circuit for armv6-m and Thumb2+Os.
>
> I tested the patch on arm-none-eabi on armv6-m/Thumb2 for both Os/O2. The
> patch introduces new fails on ARMv6-m:
>
>
Oh, and while you are there please add 2012 to the copyright years.
Ramana
On Wed, Nov 14, 2012 at 10:30 PM, Matthias Klose wrote:
> The following patch adds the multiarch definitions for arm-linux-gnu. Tested
> using a Debian/Ubuntu package build. Ok for the trunk?
>
> Matthias
>
On 11/21/12 16:27, Andrew Pinski wrote:
On Wed, Nov 21, 2012 at 8:21 AM, Konstantin Serebryany
wrote:
On Wed, Nov 21, 2012 at 8:05 PM, Peter Bergner wrote:
On Wed, 2012-11-21 at 19:39 +0400, Konstantin Serebryany wrote:
On Wed, Nov 21, 2012 at 7:29 PM, David Miller wrote:
From: Konstantin
While trying to add support for ARM (AArch32 GNU / Linux) implementation for
GCC after-hours but still keep seeing failures on my chromebook running an
ubuntu fs on a ChrOS kernel, because the shadow memory apparently overlaps
with normal memory. Has anyone else hit this while porting ?
I've he
, 2012 2:36 PM
>> To: gcc-patches@gcc.gnu.org
>> Cc: Ramana Radhakrishnan; Richard Earnshaw; 'Richard Sandiford'
>> Subject: RE: [PING Updated]: [PATCH GCC/ARM] Fix problem that
> hardreg_cprop
>> opportunities are missed on thumb1
>>
>> Ping.
>>
&
On Wed, Nov 21, 2012 at 7:59 PM, Matthew Gretton-Dann
wrote:
> All,
>
> The attached patch fixes PR54974.
>
> In Thumb when calculating the PC value for a literal load the value used is
> the current PC rounded down to the nearest multiple of 4. The ARM backend
> currently does not take this into
> gcc/ChangeLog
>
> 2012-11-14 Kyrylo Tkachov
>
> * config/arm/arm.h (TARGET_FPU_ARMV8): New macro.
> * config/arm/arm.md (UNSPEC_VRINTZ, UNSPEC_VRINTP, UNSPEC_VRINTM,
> UNSPEC_VRINTR, UNSPEC_VRINTX, UNSPEC_VRINTA): New unspecs.
> (f_rints, f_rintd): New types.
On Wed, Nov 14, 2012 at 1:52 PM, Kyrylo Tkachov wrote:
> Hi all,
>
> This patch adds the new tests for the vrint instructions in aarch32.
> It also adds an effective target check to see if we support an ARMv8 VFP and
> an add_options
> procedure for adding the required options to a testcase if we
On Wed, Nov 21, 2012 at 6:40 PM, Greta Yorsh wrote:
> This patch adjusts the definition of TARGET_LDRD to false on Thumb1 targets,
> as suggested here:
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02048.html
>
> No regression on qemu for arm none-eabi with arch=armv5t/armv7-a
> mode=thumb/arm.
>
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that there were no changes in assembly
output for a set of gcc .ii files. On the other hand, the -march=octeon
output for a set of mips64-linux-gnu gcc .ii files showed the optimisation
kicking in as h
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
wrote:
> Ramana Radhakrishnan writes:
>>> Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
>>> Also tested by making sure that there were no changes in assembly
>>> output for a set of gcc .ii
On Tue, Nov 27, 2012 at 8:47 PM, Mike Stump wrote:
> On Nov 27, 2012, at 8:51 AM, James Greenhalgh
> wrote:
>> In particular, we add support for vectorizing across:
>>
>> ceil (), ceilf (), lceil (),
>
>> We add testcases ensuring that each of the expected functions are
>> vectorized. As the i38
On Sun, Oct 7, 2012 at 8:56 AM, Richard Sandiford
wrote:
> Eric Botcazou writes:
>>> I think modelling it as a TRUNCATE operation is correct for
>>> !TRULY_NOOP_TRUNCATION (it's the bug that Andrew pointed out).
>>> And we shouldn't generate an actual TRUNCATE rtx for
>>> TRULY_NOOP_TRUNCATION (t
On 11/28/12 10:25, Richard Biener wrote:
On Tue, Nov 27, 2012 at 11:45 PM, Ramana Radhakrishnan
wrote:
On Tue, Nov 27, 2012 at 8:22 PM, Richard Sandiford
wrote:
Ramana Radhakrishnan writes:
Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf.
Also tested by making sure that
On Thu, Nov 29, 2012 at 2:27 PM, Kyrylo Tkachov wrote:
> Hi all,
> This patch adds support for the vrint builtins. It also gathers the unspec
> definitions in the various .md files in one file: unspecs.md.
> A new iterator is defined that iterates over some new unspecs, in a similar
> way to the s
701 - 800 of 1421 matches
Mail list logo
