t there is a couple of regression in the
testsuite I'm looking at on
- gcc.c-torture/execute/ieee/fp-cmp-4l.c
- c-c++-common/torture/complex-sign-mul-minus-one.c
for instance.
Any comments ?
Thanks
Yvan
On 6 July 2013 01:12, Vladimir Makarov wrote:
> On 13-07-05 8:43 AM, Yvan Ro
Sorry for the previous off-the-list-html-format answer :(
On 30 August 2013 15:18, Richard Earnshaw wrote:
> On 30/08/13 14:09, Yvan Roux wrote:
>> Hi,
>>
>> here is a request for comments on the 2 attached patches which enable
>> the build of GCC on ARM with LRA.
13 01:23, Vladimir Makarov wrote:
> On 13-09-08 2:04 PM, Richard Sandiford wrote:
>>
>> Yvan Roux writes:
>>>
>>> @@ -5786,7 +5796,11 @@ get_index_scale (const struct address_info *info)
>>> && info->index_term == &XEXP (index, 0))
&g
Hi,
here are the modifications, discussed in another thread, needed in
rtlanal.c by ARM targets (AArch32 and AArch64) to build GCC with LRA.
Is it ok for trunk ?
Thanks,
Yvan
2013-09-09 Yvan Roux
Vladimir Makarov
* rtlanal.c (must_be_index_p, set_address_index): Add
Thanks for noticing it Richard, I made a refactoring mistake and addr
was supposed to be used instead of x. In fact on AArch64 it occurs
that we don't have stripped rtxes at this step and we have some of the
form below, this if why I added the strip.
(insn 29 27 5 7 (set (mem:SI (plus:DI (sign_ex
> Yeah, but that's because strip_address_mutations doesn't consider
> SIGN_EXTRACT to be a "mutation" as things stand. My point was that
> I think it should, at least for the special extract-from-lsb case.
> It then shouldn't be necessary to handle SIGN_EXTRACT in the other
> address-analysis rout
> Endianness in the BYTES_BIG_ENDIAN sense shouldn't be a problem AFAIK.
> We just need to worry about BITS_BIG_ENDIAN. For:
>
> ({sign,zero}_extract:m X len pos)
>
> "pos" counts from the lsb if !BITS_BIG_ENDIAN and from the msb if
> BITS_BIG_ENDIAN. So I think the condition should be somethin
New attempt, with fixes from Richard's comments (discussed in the other thread).
Thanks,
Yvan
2013-09-09 Yvan Roux
Vladimir Makarov
* rtlanal.c (strip_address_mutations): Add bitfield operations
handling.
(shift_code_p): New predicate for shi
align to X bytes. */
loc = &XEXP (*loc, 0);
if you think that it doesn't affect too much the readability.
Many Thanks,
Yvan
On 11 September 2013 09:32, Richard Sandiford
wrote:
> Yvan Roux writes:
>> @@ -5454,6 +5454,16 @@ strip_address_mutations (rtx *loc, enu
> Yeah, good point. TBH I prefer it with separate ifs though, because the
> three cases are dealing with three different types of rtl (unary, binary
> and ternary). But I don't mind much either way.
Ok, it's fine for me too.
> The new patch looks good to me, thanks. Just one minor style nit:
>
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11 Yvan Roux
Vladimir Makarov
* rtlanal.c (lsb_bitfield_op_p): New predicate for bitfield operations
from the least significant bit.
(strip_address_mutations): Add bitfield
Adding Eric and Steven in the loop as it is RTL related.
Thanks
Yvan
On 11 September 2013 21:08, Yvan Roux wrote:
> Here is the new patch discussed in the other thread.
>
> Thanks
> Yvan
>
> 2013-09-11 Yvan Roux
> Vladimir Makarov
>
> * r
is removed. I'm currently working on
this issue.
- Thumb still doesn't bootstrap.
Thanks,
Yvan
On 11 September 2013 20:57, Yvan Roux wrote:
>> Yeah, good point. TBH I prefer it with separate ifs though, because the
>> three cases are dealing with three different types
Hi,
this patch fix the scan-assembler pattern of
gcc.target/arm/atomic-comp-swap-release-acquire.c, which didn't
allowed aliases register and failed when enabling LRA where 'ip' is
used in the ldaex instruction.
Thanks,
Yvan
2013-09-24 Yvan Roux
* gcc.target/arm/a
Ping
On 16 September 2013 10:57, Yvan Roux wrote:
> Adding Eric and Steven in the loop as it is RTL related.
>
> Thanks
> Yvan
>
> On 11 September 2013 21:08, Yvan Roux wrote:
>> Here is the new patch discussed in the other thread.
>>
>> Thanks
.html
Thanks,
Yvan
2013-09-24 Yvan Roux
* config/aarch64/aarch64.opt (mlra): New option.
* config/aarch64/aarch64.c (aarch64_lra_p): New function.
(TARGET_LRA_P): Define.
aarch64-lra.diff
Description: Binary data
Hi,
> Fair enough - we should just fix the test and move on.
Done.
> I would suggest in addition a transitional command-line option to switch
> between LRA and reload as a temporary measure so that folks can do some more
> experimenting for AArch32.
I've a patch which fixes the REG_NOTE issues,
Hi Eric,
Thanks for the review.
> +/* Return true if X is a sign_extract or zero_extract from the least
> + significant bit. */
> +
> +static bool
> +lsb_bitfield_op_p (rtx x)
> +{
> + if (GET_RTX_CLASS (GET_CODE (x)) == RTX_BITFIELD_OPS)
> +{
> + enum machine_mode mode = GET_MODE(x)
Hi,
This patch removes REG_DEAD and REG_UNUSED notes in update_inc_notes,
as it is what the function is supposed to do (see the comments) and as
keeping these notes produce some failures, at least on ARM.
Thanks,
Yvan
2013-09-24 Yvan Roux
* lra.c (update_inc_notes): Remove all
> So can we assert that we have a REG here and use GET_MODE (XEXP (x, 0))? Or
> else return false if we don't have a REG.
I'm currently testing the patch with the modification below
+static bool
+lsb_bitfield_op_p (rtx x)
+{
+ if (GET_RTX_CLASS (GET_CODE (x)) == RTX_BITFIELD_OPS)
+{
+
Thanks Eric, here is the new patch, validation is ongoing for ARM.
Yvan
2013-09-24 Yvan Roux
Vladimir Makarov
* rtlanal.c (lsb_bitfield_op_p): New predicate for bitfield operations
from the least significant bit.
(strip_address_mutations): Add bitfield
> The description is too terse. In the RTL middle-end, you shouldn't have to
> manually deal with the REG_DEAD and REG_UNUSED notes (unlike REG_EQUAL and
> REG_EQUIV notes), as the DF framework is supposed to do it for you.
Sorry, for that. The description of the LRA function update_inc_notes
ex
hmm, I don't see clearly where we loose the XEXP (x, n) information
when calling must_be_base_p(*inner) and/or must_be_index_p(*inner) in
set_address_base and set_address_index.
BTW, the validation on ARM (AARch32 and AARch64) is clean.
Thanks,
Yvan
On 24 September 2013 18:36, Richard Sandiford
Hi,
the needed lra analyser patch was commited as r202914.
Thanks,
Yvan
On 24 September 2013 11:03, Yvan Roux wrote:
> Hi,
>
> The following patch switch LRA on for AArch64. The patch introduces
> an undocumented option -mlra to use LRA instead of reload, for a
> testing p
(Added Eric and Richard)
Sorry for the inconvenience Iain, It's ok for my side.
Thanks,
Yvan
On 26 September 2013 13:18, Iain Sandoe wrote:
> Hi Yvan,
>
> On 24 Sep 2013, at 09:29, Yvan Roux wrote:
>
>>> On 11 September 2013 21:08, Yvan Roux wrote:
>>>>
Hi,
The status of LRA support for AArch32 is the sequel :
- there is some regressions in the testsuite (gcc/g++, libstdc++ and
fortran) in ARM mode, all due to the same neon legitimate address
issue (tested in hard and softfp mode).
- the compiler doesn't bootstrap with LRA enable for thumb (durin
Hi,
after the discussion in the thread below I've committed the enabling
of LRA on ARM through the new option -mlra. Notice that we still rely
on reload until the regression has been resolved.
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00908.html
Thanks,
Yvan
2013-10-16 Yvan
Ping^2
I forgot this one was still pending.
On 13 August 2013 14:21, Yvan Roux wrote:
> Ping.
>
> On 23 July 2013 16:18, Yvan Roux wrote:
>> Hi,
>>
>> I forgot to add the test case with the PR fix, the attached patch add it.
>>
>> Thanks,
>> Yvan
&
(this time in plain text !)
> Does this mean we can now turn on LRA for ARM state by default and
> start looking at performance issues if any ?
With the other patch for 58785 and a small one I've to post, we are even
about to turn LRA on by default completely, as the compiler now bootstrap
also i
Hi,
On 26 January 2015 at 18:01, Matthew Wahab wrote:
> Hello,
>
> The LEGITIMIZE_RELOAD_ADDRESS macro is only needed for reload. Since the
> Aarch64 backend no longer supports reload, this macro is not needed and this
> patch removes it.
>
> Tested aarch64-none-linux-gnu with gcc-check. No new f
Ping
On 18 November 2013 09:40, Yvan Roux wrote:
> Ping.
>
> On 7 November 2013 15:56, Yvan Roux wrote:
>> Hi,
>>
>> this patch fixed an LRA cycling due to secondary reload (Thumb mode).
>> Notice that this patch is a prerequisite to turn on LRA by default on
&g
Ping.
On 19 November 2013 09:52, Yvan Roux wrote:
>> yep, all good performance-wise :)
>
> Great, Thanks Kyrill.
>
> Ok for trunk ?
>
> Yvan
Ping.
On 20 November 2013 10:22, Yvan Roux wrote:
> Hi,
>
> as Richard said, only a subset of rclass is allowed to be returned by
> preferred_reload_class. I've tested the attached patched in Thumb
> mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
>
>
> Please include either the patch you are pinging or at the least a link to it
> in the archives.
Ok, sorry for that, here is the patch and Changelog
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p.
diff --git
> How can that be correct?
>
> The secondary reload macros/hooks define cases where additional registers
> are needed to reload certain forms of rtl. I doubt the use of LRA
> completely eliminates the need for secondary reloads.
Vladimir explained me that in that case on arm, secondary reload hoo
On 27 November 2013 18:58, Vladimir Makarov wrote:
> On 11/27/2013, 12:16 PM, Jeff Law wrote:
>>
>> On 11/27/13 03:18, Yvan Roux wrote:
>>>
>>> Ping
>>>
>>> On 18 November 2013 09:40, Yvan Roux wrote:
>>>>
>>>>
On 27 November 2013 19:13, Jeff Law wrote:
> On 11/27/13 10:30, Yvan Roux wrote:
>>>
>>> Please include either the patch you are pinging or at the least a link to
>>> it
>>> in the archives.
>>
>>
>> Ok, sorry for that, here is the patc
d discussed the patch with Richard
offline, but was a bit lazy in the description ;)
> I've tested the attached patched in Thumb
>>>
>>> mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
>>>
>>> Yvan
>>>
>&
On 27 November 2013 19:27, Jeff Law wrote:
> On 11/27/13 10:49, Yvan Roux wrote:
>>>
>>> How can that be correct?
>>>
>>> The secondary reload macros/hooks define cases where additional registers
>>> are needed to reload certain forms of rtl. I do
Hi Vladimir,
I've some regressions on ARM after this SP elimination patch, and they
are execution failures. Here is the list:
g++.dg/cilk-plus/AN/array_test_ND_tplt.cc -O3 -fcilkplus
gcc.c-torture/execute/va-arg-22.c -O2
gcc.dg/atomic/c11-atomic-exec-5.c -O0
gfortran.dg/direct_io_12.f90 -O[2
> Pragmatically, I think it's time we turned LRA on by default now that
> we are in stage3 and that would help with getting more issues out of
> the auto-testers quicker than anything else. Given we are now well
> into stage3, we should make sure that the LRA support gets as much
> testing as it ca
Thanks
Yvan
2013-12-11 Yvan Roux
* config/arm/arm.opt (mlra): Enable LRA by default.
Index: gcc/config/arm/arm.opt
===
--- gcc/config/arm/arm.opt (revision 205885)
+++ gcc/config/arm/arm.opt (working copy
On 11 December 2013 19:25, Vladimir Makarov wrote:
> On 12/11/2013, 5:35 AM, Yvan Roux wrote:
>>
>> Hi Vladimir,
>>
>> I've some regressions on ARM after this SP elimination patch, and they
>> are execution failures. Here is the list:
>>
>&
bootstrap seems to be broken with an ICE in check_rtl, I'm
checking if it is the same issue.
Yvan
On 12 December 2013 20:18, Vladimir Makarov wrote:
> On 12/11/2013, 1:59 PM, Yvan Roux wrote:
>>
>> On 11 December 2013 19:25, Vladimir Makarov wrote:
>>>
>>> O
Thanks for the fix Vladimir, I confirm that most of ARM regression are
fixed, and Thumb2 bootstrap is ok. I'm still working on sorting out
the remaining regressions, most of them are on Thumb1.
Thanks
Yvan
On 13 December 2013 22:10, Vladimir Makarov wrote:
> On 12/13/2013, 4:02 PM, Jakub Jelinek
On 17 December 2013 00:03, Vladimir Makarov wrote:
> On 12/13/2013, 8:07 AM, Yvan Roux wrote:
>>
>> Thanks for your help Vlad. Another bad news about this PR fix, is
>> that it has resurrected the thumb_movhi_clobber bug (PR 58785) but in
>> a different manner as th
Hi,
this patch from Vladimir fixes an ICE when compiling newlib in Thumb1.
It returns NO_REGS in THUMB_SECONDARY_OUTPUT_RELOAD_CLASS, the same
way we did for THUMB_SECONDARY_INPUT_RELOAD_CLASS.
The testsuite is OK with this patch, but as we have also a regression
on iWMMXT, I tried to avoid the
> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>
> arm.c: && !(reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_co
Thanks for the hint Vladimir, I'll pass some validation on arm.c and
arm.md/aarch64.md separately.
On 14 January 2014 20:09, Vladimir Makarov wrote:
> On 01/14/2014 01:41 PM, Yvan Roux wrote:
>>> A quick grep of the arm backend shows 11 instances of reload_in_progre
2012-02/msg00320.html
>
> Yes, that seems better.
I've rebased the patch on trunk, bootstrap is ok and when configuring
with options:
"--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.9.2"
gcc_gxx_include_dir keeps its leading slash.
Is it ok for trunk ?
Thanks,
Yvan
Hi Kyrill,
On 27 October 2015 at 13:08, Ramana Radhakrishnan
wrote:
> On Wed, Oct 14, 2015 at 1:23 PM, Kyrill Tkachov
> wrote:
>> Hi all,
>>
>> This patch fixes the referenced PR by rewriting the
>> vfp3_const_double_for_bits function in arm.c
>> The function is supposed to accept positive CONS
On 2 November 2015 at 09:38, Ramana Radhakrishnan
wrote:
>
2015-10-12 Kyrylo Tkachov
PR target/67929
* gcc.target/arm/pr67929_1.c: New test.
>>
>> This test fails when tested on hard-float targets, adding the
>> following line to avoid testing it in such cases w
On 2 November 2015 at 10:24, Ramana Radhakrishnan
wrote:
>
>
> On 02/11/15 09:01, Christophe Lyon wrote:
>> On 2 November 2015 at 09:51, Yvan Roux wrote:
>>> On 2 November 2015 at 09:38, Ramana Radhakrishnan
>>> wrote:
>>>>
>>>>>&g
Hi Kyrill,
On 24 November 2015 at 14:31, Kyrill Tkachov wrote:
> Ping.
>
> Thanks,
> Kyrill
>
>
>
> On 13/11/15 11:50, Kyrill Tkachov wrote:
>>
>> Ping.
>> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg00686.html
>>
>> Thanks,
>> Kyrill
>>
>> On 06/11/15 17:05, Kyrill Tkachov wrote:
>>>
>>> Hi al
Hi Wilco,
> Enable instruction fusion of AES instructions on ARM for Cortex-A53 and
> Cortex-A57.
I've a question regarding Cortex-A35, I don't see the same
documentation for it on ARM website as we have for the other cores
yet, but is AES fusion not beneficial for it or is it planned to do it
la
On 25 November 2015 at 11:36, Kyrill Tkachov wrote:
> Hi Yvan,
>
>
> On 24/11/15 15:05, Yvan Roux wrote:
>>
>> Hi Kyrill,
>>
>> On 24 November 2015 at 14:31, Kyrill Tkachov
>> wrote:
>>>
>>> Ping.
>>>
>>> Thanks,
>
Hi,
On 25 November 2015 at 14:54, Bernd Schmidt wrote:
> On 11/25/2015 01:21 PM, Richard Sandiford wrote:
>>
>> - (plus:SI (match_operand:SI 0 "s_register_operand" "l, r")
>> - (match_operand:SI 1 "arm_add_operand""lPv,rIL"))
>> + (plus:SI (match_operand:SI 0
Hi,
This patch adds Linaro version string and release macros to ARM GCC 8
vendor branch.
Ok to commit?
Thanks
Yvan
gcc/ChangeLog
2018-08-10 Yvan Roux
* LINARO-VERSION: New file.
* configure.ac: Add Linaro version string.
* configure: Regenerate.
* Makefile.in (LINAROVER
On Fri, 10 Aug 2018 at 13:45, Ramana Radhakrishnan
wrote:
>
> On Fri, Aug 10, 2018 at 11:09 AM, Yvan Roux wrote:
> > Hi,
> >
> > This patch adds Linaro version string and release macros to ARM GCC 8
> > vendor branch.
> >
> > Ok to commit?
> >
On Fri, 10 Aug 2018 at 14:31, Yvan Roux wrote:
>
> On Fri, 10 Aug 2018 at 13:45, Ramana Radhakrishnan
> wrote:
> >
> > On Fri, Aug 10, 2018 at 11:09 AM, Yvan Roux wrote:
> > > Hi,
> > >
> > > This patch adds Linaro version string and
On Fri, 10 Aug 2018 at 17:01, Ramana Radhakrishnan
wrote:
>
> On Fri, Aug 10, 2018 at 3:35 PM, Yvan Roux wrote:
> > On Fri, 10 Aug 2018 at 14:31, Yvan Roux wrote:
> >>
> >> On Fri, 10 Aug 2018 at 13:45, Ramana Radhakrishnan
> >> wrote:
> >> >
e bug is still present since compiling
gcc.target/aarch64/pr78733.c with -mcmodel=large brings back the
:lo12: relocations (I'll submit a patch to add the test back if my
understanding is correct).
Cross built and regtested without issue for aarch64-linux-gnu,
aarch64-none-elf and aarch64_be-no
Hi,
On 22 June 2017 at 20:42, Yvan Roux wrote:
> Hi all,
>
> On 16 January 2017 at 16:34, Kyrill Tkachov
> wrote:
>>
>> On 13/01/17 16:35, James Greenhalgh wrote:
>>>
>>> On Wed, Jan 11, 2017 at 04:32:45PM +, Kyrill Tkachov wrote:
>>>&g
Hi Wilco
On 27 June 2017 at 12:53, Wilco Dijkstra wrote:
> Hi Yvan,
>
>> Here is the backport of Wilco's patch (r237607) along with Kyrill's
>> one (r244643, which removed the remaining occurences of
>> aarch64_nopcrelative_literal_loads). To fix the issue the original
>> patch has to be modifie
trunk ?
Thanks
Yvan
gcc/ChangeLog
2017-06-27 Yvan Roux
* config/aarch64/aarch64.opt
(mpc-relative-literal-loads): Remove redundant property.
* doc/invoke.texi (AArch64): Add missing options.
diff --git a/gcc/config/aarch64/aarch64.opt b/gcc/config/aarch64/aarch64.opt
in
Hi
On 27 June 2017 at 16:49, Wilco Dijkstra wrote:
> As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
> may be used to avoid generating ADRP/ADD or ADRP/LDR. However both
> trunk and GCC7 may still emit ADRP for some constant pool literals.
> Fix this by adding a aarch64_pcrel
On 27 June 2017 at 16:55, Yvan Roux wrote:
> Hi
>
> On 27 June 2017 at 16:49, Wilco Dijkstra wrote:
>> As described in PR79041, -mcmodel=large -mpc-relative-literal-loads
>> may be used to avoid generating ADRP/ADD or ADRP/LDR. However both
>> trunk and GCC7 m
Hi Sandra,
On 27 June 2017 at 18:05, Sandra Loosemore wrote:
> On 06/27/2017 06:19 AM, Yvan Roux wrote:
>
>> diff --git a/gcc/config/aarch64/aarch64.opt
>> b/gcc/config/aarch64/aarch64.opt
>> index 942a7d5..0fd1bfa 100644
>> --- a/gcc/config/aarch64/aarch64.o
On 23 June 2017 at 15:44, Yvan Roux wrote:
> Hello,
>
> Fortran parts of libgomp (omp_lib.mod, openacc.mod, etc...) are
> missing in a canadian cross build, at least when target gfortran
> compiler comes from PATH and not from GFORTRAN_FOR_TARGET.
>
> Back in 2010, executabi
On 27 June 2017 at 13:14, Yvan Roux wrote:
> Hi Wilco
>
> On 27 June 2017 at 12:53, Wilco Dijkstra wrote:
>> Hi Yvan,
>>
>>> Here is the backport of Wilco's patch (r237607) along with Kyrill's
>>> one (r244643, which removed the remaining occ
On 5 October 2017 at 13:38, Petr Ovtchenkov wrote:
> On Thu, 5 Oct 2017 12:56:36 +0200
> Yvan Roux wrote:
>
>> On 5 September 2017 at 12:04, Jakub Jelinek wrote:
>> > On Tue, Sep 05, 2017 at 10:58:22AM +0200, Yvan Roux wrote:
>> >> ping
>> >>
Hi all
we have merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 213802 as r213944. We have also backported this set of revisions:
r204251 as r213841 PR sanitizer/58543
r206529 as r213842 PR target/59744
r206530 as r213842 PR target/59744 / fix changelog typo
Th
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 213803 as r213943. We have also backported this set of revisions:
r211140 as r213455 [AArch64] Drop ISB after FPCR write.
r211270 as r213790 [AArch64] Remove from arm_neon.h functions not
in the spec
r21
Hi,
as reported in PR62248 there is a typo in gcc/config.gcc where
--with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
config.gcc). Here is the patch to fix it.
Thanks,
Yvan
2014-08-27 Yvan Roux
* config.gcc: Fix fp-armv8 option for arm*-*-* targets.
diff --
On 27 August 2014 11:24, Richard Earnshaw wrote:
> On 27/08/14 09:04, Yvan Roux wrote:
>> Hi,
>>
>> as reported in PR62248 there is a typo in gcc/config.gcc where
>> --with-fpu doesn't match -mfpu option for fp-armv8 value (fp-arm-v8 in
>> config.gcc). Her
Here is the patch that uses the arm-fpus.def list.
Thanks
Yvan
2014-08-27 Yvan Roux
* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
On 27 August 2014 12:35, Yvan Roux wrote:
> On 27 August 2014 11:24, Richard Earnshaw wrote:
>> On 27/08/14 09:04, Yvan R
with the PR in the ChangeLog:
2014-08-27 Yvan Roux
PR other/62248
* config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def.
On 27 August 2014 13:10, Yvan Roux wrote:
> Here is the patch that uses the arm-fpus.def list.
>
> Thanks
> Yvan
>
> 201
Committed on trunk at r214573, and I'll backport it on 4.9 branch.
On 27 August 2014 14:26, Richard Earnshaw wrote:
> On 27/08/14 12:35, Yvan Roux wrote:
>> with the PR in the ChangeLog:
>>
>> 2014-08-27 Yvan Roux
>>
>> PR other/62248
>>
"true" seems to be used that way for aarch64*-*-* and arm*-*-* is it
preferable to change it to ";" for all occurrences ?
Thanks,
Yvan
On 27 August 2014 18:51, Bernhard Reutner-Fischer wrote:
> On 27 August 2014 16:22:28 CEST, Yvan Roux wrote:
>>Committed
On 27 August 2014 19:07, Yvan Roux wrote:
> "true" seems to be used that way for aarch64*-*-* and arm*-*-* is it
> preferable to change it to ";" for all occurrences ?
sorry for the typo, I meant colon and not semicolon.
> Thanks,
> Yvan
>
> On 27 Augus
1 [ D.5235 ])
(expr_list:REG_UNUSED (reg:CC 100 cc)
(nil
Thanks,
Yvan
On 31 October 2013 17:31, Yvan Roux wrote:
> (this time in plain text !)
>
>> Does this mean we can now turn on LRA for ARM state by default and
>> start looking at performance issues if an
when LRA is on.
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg00725.html
Thanks,
Yvan
2013-11-07 Yvan Roux
* config/arm/arm.h (THUMB_SECONDARY_INPUT_RELOAD_CLASS): Return NO_REGS
for LRA.
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 1781b75..d054906 100644
Hi,
I'm agree. I looked at the ARM backend and it occurs that the usage
of optimize_insn_for_size_p() was added to only use store_minmax in
cold path because of some performance issue. But in any case its
usage doesn't shrink the number of instruction, if we are in ARM mode
3 are needed : 1 comp
> Sometimes 4 will be needed, since both original register values may
> remain live.
Indeed.
> However, I'm inclined to agree that while it should be possible to
> decide at the *function* level whether or not an insn is valid, doing so
> at the block level is probably unsafe.
Ok, so the attache
So, the validation is ok with this patch, I'm just not able to say if
the original performance issue is still fixed with it. Could you
check it Kyrylo ?
Yvan
2013-11-17 Yvan Roux
* config/arm/arm.md (store_minmaxsi): Use only when
optimize_function_for_size_p.
Ping.
On 7 November 2013 15:56, Yvan Roux wrote:
> Hi,
>
> this patch fixed an LRA cycling due to secondary reload (Thumb mode).
> Notice that this patch is a prerequisite to turn on LRA by default on
> ARM. Bootstrapped on a9 and a15 without any regression in the
> testsuit
> Hi Yvan,
> I'll run the benchmark today to confirm the performance, but from compiling
> some code sequences that exhibited the bad behaviour in the past, I see that
> this patch still fixes the issues. store_minmaxsi is not generated when
> optimising for speed.
Ok Cool, Thanks Kyrill
Cheers,
> yep, all good performance-wise :)
Great, Thanks Kyrill.
Ok for trunk ?
Yvan
Hi,
as Richard said, only a subset of rclass is allowed to be returned by
preferred_reload_class. I've tested the attached patched in Thumb
mode, on ARMv5, A9 and A9hf and on cross A15 without regression.
Yvan
2013-11-20 Yvan Roux
PR target/58785
* config/arm/
Hi all
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 216130 as r216256. We have also backported this set of revisions:
r209643 as 215975 : [AArch64] Define TARGET_FLAGS_REGNUM
r211881 as 215975 : PR target/61565
r213035 as 215846 : [AArch64] libitm: Improve _ITM_beg
Hi all,
we have merged the gcc-4_9-branch into linaro/gcc-4_9-branch up to
revision 211054 as r211495. We have also backported this set of revisions:
r209419 as r211497 : PR rtl-optimization/60663
r209457 as r211496 : TRY_EMPTY_VM_SPACE Change aarch64 ilp32
r209559 as r211498 : [AArch64] vrnd<*>
Hi all,
we have backported a set of AArch64 costs model related revisions in
the linaro/gcc-4_9-branch at r211843. The backported revisions are:
210493 : [AArch64 costs 1/18] Refactor aarch64_address_costs.
210494 : [AArch64 costs 2/18] Add cost tables for Cortex-A57
210495 : [AArch64 costs 3/18
Hi,
we have merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to
revision 210799 as r211850.
Thanks
Yvan
Hi,
On 5 May 2015 at 10:11, Marcus Shawcroft wrote:
> On 4 May 2015 at 09:58, Yvan Roux wrote:
>
>> Yes this is a better formulation.
>>
>>> +corresponding flag to the linker. It can be explicitly disabled
>>> during
>>> +compilation by passing t
Hi,
On 8 May 2015 at 00:07, Joseph Myers wrote:
> On Mon, 20 Apr 2015, Pavel Kopyl wrote:
>
>> Hi all,
>>
>>
>> To build a GCC-4.9.2 ARM cross-compiler for my setting I need to configure it
>> with "--with-sysroot=/ --with-gxx-include-dir=/usr/include/c++/4.9.2".
>> But I found that gcc driver r
to have a real difference between alu or multiple
instruction and mov.
Bootstrapped and regtested on arm-linux-gnueabihf. Ok for trunk ?
Thanks,
Yvan
2015-04-27 Yvan Roux
* config/arm/arm.mb (*arm_movt): Fix type attribute.
(*movsi_compare0): Likewise.
(*cmpsi_shi
On 27 April 2015 at 15:20, Kyrill Tkachov wrote:
> Hi Yvan,
>
>
> On 27/04/15 13:25, Yvan Roux wrote:
>>
>> Hi,
>>
>> This is a follow-up of PR64208 where an LRA loop was due to redundancy
>> in insn's alternatives. I've checked all the insn
Hi,
On 27 April 2015 at 15:58, Yvan Roux wrote:
> On 27 April 2015 at 15:20, Kyrill Tkachov wrote:
>> Hi Yvan,
>>
>>
>> On 27/04/15 13:25, Yvan Roux wrote:
>>>
>>> Hi,
>>>
>>> This is a follow-up of PR64208 where an LRA loop was
Hi,
here is the patch for PR65924, only tested on the original testcase so far.
Thanks
Yvan
gcc/
2015-04-29 Yvan Roux
PR target/65924
* config/arm/thumb2.md (*thumb2_addsi3_compare0_scratch): Fix operand
number in type attribute expression.
gcc/testsuite/
2015-04-29 Yvan Roux
Hi Kyrill,
On 29 April 2015 at 12:06, Kyrill Tkachov wrote:
> Hi Yvan,
>
> On 29/04/15 09:57, Yvan Roux wrote:
>>
>> Hi,
>>
>> here is the patch for PR65924, only tested on the original testcase so
>> far.
>
>
> Can you please double check that th
1 - 100 of 189 matches
Mail list logo
