On Thu, Nov 13, 2014 at 4:55 PM, Sandra Loosemore
wrote:
> This patch to the AArch64 back end adds a couple of additional bics patterns
> to match code of the form
>
> if ((x & y) == x) ...;
>
> This is testing whether the bits set in x are a subset of the bits set in y;
> or, that no bits in x
On Fri, Nov 14, 2014 at 11:11 AM, Marcus Shawcroft
wrote:
> On 14 November 2014 10:50, James Greenhalgh wrote:
>> On Fri, Nov 14, 2014 at 10:42:27AM +, Andrew Pinski wrote:
>>> On Fri, Nov 14, 2014 at 2:35 AM, James Greenhalgh
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > We currently do not set an
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 of
On Wed, Nov 12, 2014 at 9:51 AM, Terry Guo 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 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 all the crypto
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?
So
On Wed, Nov 12, 2014 at 4:38 PM, Kyrill Tkachov 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 arithmetic
> operation
On Wed, Nov 12, 2014 at 5:08 PM, James Greenhalgh
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 that the ARM target a
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 bu
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 reg
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 VAR. 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.
O
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 tes
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 ca
On Mon, Nov 17, 2014 at 5:06 AM, Hale Wang 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 if we define
On Mon, Nov 10, 2014 at 3:02 PM, Christophe Lyon
wrote:
> On 30 October 2014 23:02, Christophe Lyon wrote:
>> On 29 October 2014 16:28, Ramana Radhakrishnan
>> wrote:
>>> On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
>>> wrote:
>>>> Hi,
>&
On Thu, Nov 13, 2014 at 9:42 AM, Kyrill Tkachov 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 for trunk?
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) 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)
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 bothers you guys.
The
On Mon, Nov 17, 2014 at 5:13 PM, Marcus Shawcroft
wrote:
> On 14 November 2014 14:35, Wilco Dijkstra wrote:
>
>> 2014-11-14 Wilco Dijkstra
>>
>> * gcc/config/aarch64/aarch64.c (generic_regmove_cost):
>> Increase FP move cost.
>
> OK /Marcus
Changelog should probably indicate P
On Tue, Nov 11, 2014 at 11:59 AM, Kyrill Tkachov 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.
>
> Bootstrapped and tes
On 14/11/14 15:12, Maxim Kuvyrkov wrote:
On Nov 14, 2014, at 8:38 AM, Jeff Law 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
share. In particular
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], HIm
On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel 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
aim to get these in f
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 i
32768. Obviously this won't be accepted
as is by the assembler and we should be using the %L character. Applied
to trunk as obvious.
Felix, How did you test this patch ?
regards
Ramana
2014-11-20 Ramana Radhakrishnan
PR target/59593
* config/arm/arm.md (*movhi_i
On Wed, Nov 19, 2014 at 9:42 PM, Philipp Tomsich
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 backend in the near
> future (movi
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov 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 option is added a
On Thu, Nov 13, 2014 at 5:25 PM, Kyrill Tkachov 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 instruction schedul
r 26, 2014 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
On Thu, Nov 13, 2014 at 4:03 PM, Thomas Preud'homme
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, August 21, 2014
homme
>> Sent: Tuesday, November 11, 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
On Tue, Nov 18, 2014 at 10:40 AM, Kyrill Tkachov 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 tuning
> decisions as
On Wed, Oct 29, 2014 at 10:20 AM, Jiong Wang 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 mod
On Wed, Nov 19, 2014 at 2:54 PM, Christian Bruel wrote:
>
>
> On 11/19/2014 03:18 PM, Ramana Radhakrishnan wrote:
>>
>> On Wed, Nov 19, 2014 at 1:24 PM, Christian Bruel
>> wrote:
>>
>>> I think I missed the stage3, Anyway would it be OK for stage
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 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
-eabi. I
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
* config/arm/t-aprofile (MULTILIB_MATCHES): New entry for
-march=arm
On 20/11/14 11:54, Tom de Vries wrote:
Richard,
This patch fixes PR63718, which currently breaks Thumb1 bootstrap.
The problem is that in Thumb1 mode, we emit the epilogue in RTL, but the last
insn - epilogue_insns - does not accurately model the corresponding insns
emitted in the asm file. F
On 29/11/14 06:50, Chen Shanyao wrote:
I've backported this fix to 4.8 & 4.9 branch.
These patches have been tested for armeb-none-eabi-gcc/g++ with qemu,
and both the test results were ok.
The Changelog should mention all authors of the original patches i.e.
include my name.
Otherwise th
On Tue, Dec 2, 2014 at 2:01 PM, Kyrill Tkachov wrote:
>
> On 23/09/14 09:27, James Greenhalgh wrote:
>>
>> On Mon, Sep 15, 2014 at 11:56:03AM +0100, Andrew Stubbs wrote:
>>>
>>> On 15/09/14 10:46, Richard Earnshaw wrote:
Hmm, I wonder if arm_override_options should reject neon + (arch <
On Fri, Nov 21, 2014 at 6:44 PM, Philipp Tomsich
wrote:
> The following patch-series adds optimized support for the APM X-Gene 1
> by providing a cost-model and pipeline-model. The pipeline-model has a
> few long reservation-chains, but looking at the stats for the generated
> NDA shows that it's
On Fri, Nov 21, 2014 at 6:44 PM, Philipp Tomsich
wrote:
> To keep this change separately buildable from the pipeline model,
> this patch directs the APM XGene-1 to use the generic scheduling
> model.
> ---
> gcc/ChangeLog| 8 +++
> gcc/config/aarch64/aarch64-cores.def |
On Fri, Nov 21, 2014 at 6:44 PM, Philipp Tomsich
wrote:
> ---
> gcc/ChangeLog | 6 +
> gcc/config/aarch64/aarch64.md | 3 +-
> gcc/config/arm/xgene1.md | 532
> ++
> 3 files changed, 540 insertions(+), 1 deletion(-)
> create mode
CCing release maintainers as well as they need to approve this
backport if Vlad is happy with it.
Vlad - is this ok to go back as it fixes a bug for ARM in the 4.9 tree
that came up in building bits of debian.
Ramana
On Mon, Dec 1, 2014 at 5:24 PM, Renlin Li wrote:
> On 01/12/14 15:58, H.J. Lu
On Tue, Nov 11, 2014 at 11:55 AM, Kyrill Tkachov wrote:
> Hi all,
>
> This is the arm implementation of the macro fusion hook.
> It tries to fuse movw+movt operations together. It also tries to take lo_sum
> RTXs into account since those generate movt instructions as well.
>
> Bootstrapped and tes
On Thu, Dec 18, 2014 at 10:13 AM, Xingxing Pan wrote:
> Hi,
>
> This patch contains Marvell Whitney core's pipeline description.
> Test on arm-linux-gnueabi and no new regression are found.
>
> Is it OK for trunk?
I haven't had a chance to review this in detail but I think it's too
late to add su
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 7bf5b4d..777230e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6392,14 +6392,8 @@ arm_set_default_type_attributes (tree type)
static bool
arm_function_in_section_p (tree decl, section *section)
{
- /* We can
On 11/03/2015 02:11, 박준모 wrote:
> Hi all,
>
> This patch only affect sha2 crypto instruction's order when gcc
> performs instruction scheduling(rtl-sched1,2).
>
> There are no definition for crypto_sha256_fast, crypto_sha256_slow on
> "cortex-a57.md".
>
> This makes poor result of instructio
Attached patch as text.
2015-03-11 Junmo Park
* config/arm/cortex-a57.md (cortex_a57_crypto_simple): Add
crypto_sha256_fast.
(cortex_a57_crypto_complex): Add crypto_sha256_slow.
Ok to commit to trunk?
OK, Thanks Sebastian.
regards
Ramana
Thanks,
Sebastia
On 03/03/15 17:59, Kyrylo Tkachov wrote:
-Original Message-
From: Kyrylo Tkachov
Sent: 27 February 2015 14:30
To: Kyrylo Tkachov; GCC Patches
Cc: Ramana Radhakrishnan; Richard Earnshaw
Subject: RE: [PATCH][ARM] PR target/64600 Fix another ICE with -
mtune=xscale: properly sign
On Fri, Mar 6, 2015 at 7:42 AM, Bin Cheng wrote:
> Hi,
> This patch is the first part fixing memset-inline-{4,5,6,8,9}.c failures on
> cortex-a9. GCC/arm doesn't generate any tuning information in assembly, it
> can't tell whether we are compiling for cortex-a9 tune if the compiler is
> configure
On Fri, Mar 6, 2015 at 7:46 AM, Bin Cheng wrote:
> Hi,
> This patch is the second part fixing memset-inline-{4,5,6,8,9}.c failures on
> cortex-a9. It adds a function checking CPU tuning information in dejagnu,
> it also uses that function to skip related testcase when we are compiling
> for corte
On Wed, Mar 18, 2015 at 10:19 AM, Yvan Roux wrote:
> Hi,
>
> This is a fix for PR64208 where LRA loops when dealing with
> iwmmxt_arm_movdi insn. As explain in the PR, the issue was introduced
> on trunk and 4.9 branch by fix of PR rtl-optimization/60969 and then
> workaround by r211798 (-fuse-ca
On Tue, Mar 17, 2015 at 3:34 AM, Bin.Cheng wrote:
> On Fri, Mar 13, 2015 at 7:56 PM, Ramana Radhakrishnan
> wrote:
>> On Fri, Mar 6, 2015 at 7:46 AM, Bin Cheng wrote:
>>> Hi,
>>> This patch is the second part fixing memset-inline-{4,5,6,8,9}.c failures on
>
On Fri, Apr 3, 2015 at 5:17 PM, Sebastian Pop wrote:
> Hi,
>
> On Thu, Apr 2, 2015 at 5:51 PM, James Greenhalgh
> wrote:
>> Trunk is currently in Stage 4 development, these patches are fairly
>> low-risk, but they are certainly not regression fixes. I'll defer
>> to port maintainers and release m
On Mon, Mar 23, 2015 at 4:15 PM, Kyrill Tkachov wrote:
> Hi all,
>
> The ICE in the PR happens on arm during the hoist pass when the code
> generates a SET rtx of the form:
> (set (reg:OI) (const_int 0)). It checks whether const_int 0 is a
> general_operand for OImode which involves asking the bac
On Thu, Apr 9, 2015 at 12:10 PM, Yvan Roux wrote:
> Hi
>
> On 7 April 2015 at 22:02, Yvan Roux wrote:
>> On 7 April 2015 at 21:33, Jakub Jelinek wrote:
>>> On Tue, Apr 07, 2015 at 09:28:51PM +0200, Yvan Roux wrote:
validation is ongoing, but here is my attempt to add this testcase,
doe
On Tue, Apr 14, 2015 at 9:33 AM, Jakub Jelinek wrote:
> On Tue, Apr 14, 2015 at 10:32:16AM +0200, Yvan Roux wrote:
>> The issue is more related to armv6 than M profile, but if it is widely
>> tested as well I can just commit the torture test if it's ok for
>> Jakub.
>
> If it is tested by enough p
On Mon, Apr 13, 2015 at 2:49 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This is an update to
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02706.html,
> rebased on top of the new cores that went in since that time.
>
> It's just a refactoring.
>
> Bootstrapped and tested on arm-linux.
>
> Ok for tr
On Tue, Apr 14, 2015 at 1:37 PM, Kyrill Tkachov wrote:
> Hi all,
>
> The load/store-multiple expanders reject a number of registers outside of
> [2-14]
> but the arm_gen_{load,store}_multiple functions that they called down to
> have an even
> stricter restriction of <= MAX_LDM_STM_OPS that is <=
On Mon, Feb 9, 2015 at 12:34 PM, Christian Bruel wrote:
> Hello,
>
> I'd like to ping with a respin of the 7 patches for
> the attribute target (thumb,arm) [0-6] :
>
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02455.html
> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02458.html
> https://gcc.
On Thu, Mar 5, 2015 at 1:34 PM, Xingxing Pan wrote:
> Hi,
>
> The expanding of widen-sum pattern always fails. The vectorizer expects the
> operands to have the same size, while the current implementation of
> widen-sum pattern dose not conform to this.
>
> This patch implements the widen-sum patt
On 22/05/15 17:56, Torvald Riegel wrote:
On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
Hi,
While writing atomic_word.h for the ARM backend to fix PR target/66200
I
thought it would make more sense to write it all up with atomic
primitives instead of providing various fragile
Sorry about missing this hunk in the original submission, was in my tree
but I hadn't spotted this as I was playing between the original AArch64
TARGET_RELAXED_ORDER and this patch.
Applied as obvious.
PR target/66200
PR target/66498
PR c++/66192
* g++.dg/testsuite/aarch64_guard1.C: Adjust tes
Hi,
A patch that's been sitting in my tree for sometime has been something
to fix up using dmb ish instead of dmb sy in the ARM backend. This
brings us in line with the AArch64 backend's behaviour as well for the
same. A future cleanup to write this in the form of memory_fences and
exploit a
Bah, Now with patch attached.
Ramana
On 10/06/15 08:44, Ramana Radhakrishnan wrote:
Sorry about missing this hunk in the original submission, was in my tree
but I hadn't spotted this as I was playing between the original AArch64
TARGET_RELAXED_ORDER and this patch.
Applied as obvious
On 27/05/15 11:25, Kyrill Tkachov wrote:
Ping.
Here is the rebased (and retested) patch after Christian's series.
Thanks,
Kyrill
On 18/05/15 11:26, Kyrill Tkachov wrote:
Hi all,
When using the short Thumb2 IT blocks we want to also restrict ifcvt so that it
will not end up generating a nu
On 18/05/15 11:26, Kyrill Tkachov wrote:
Hi all,
When using the short Thumb2 IT blocks we want to also restrict ifcvt so that it
will not end up generating a number of back-to-back cond_execs
that will later end up being back to back single-instruction IT blocks.
Branching over them should b
On Fri, Jun 12, 2015 at 10:06 AM, Jonathan Wakely wrote:
> On 11/06/15 23:56 +0200, Torvald Riegel wrote:
>>>
>>> > On Fri, 2015-05-22 at 12:37 +0100, Ramana Radhakrishnan wrote:
>>> I don't think we can remove _GLIBCXX_READ_MEM_BARRIER and
>>> _GL
On 16/06/15 09:54, Eric Botcazou wrote:
This is the C front-end + C family part.
* doc/extend.texi (type attributes): Document scalar_storage_order.
* doc/invoke.texi (Warnings): Document -Wno-scalar-storage-order.
c-family/
* c-common.c (c_common_attributes): Add scala
On Tue, Jun 16, 2015 at 1:35 PM, Christian Bruel wrote:
> Hi,
>
> This fixes the torture/pr52429.c regression due to arm_set_current_function
> that needs to handle DECL_FUNCTION_SPECIFIC_TARGET when set to
> target_option_default_node.
>
> Catch up with x86 and rs6000 backends.
>
> no regression
I am not very familiar with this feature entirely so please bear with me
during review and will find some time to do some experiments with the
feature during this week, but a couple of things with respect to the
patch immediately spring to mind.
+(define_insn "probe_stack_range"
+ [(set (ma
On Mon, Jun 22, 2015 at 7:11 PM, Alexander Monakov wrote:
> On Mon, 22 Jun 2015, Jiong Wang wrote:
>> Have done a quick experiment, -fno-plt doesn't work on AArch64.
>>
>> it's because although this patch force the function address into register,
>> but the combine pass runs later combine it back
On 16/06/15 22:25, James Lemke wrote:
A divide by zero exception was not giving a proper traceback for LINUX
ARM_EABI. The attached patch fixes the problem on trunk (and several
local branches).
Tested on gcc-trunk for arm-none-linux-gnueabi.
OK to commit?
>
2015-06-16 James Lemke
On Tue, Jun 23, 2015 at 5:18 PM, James Lemke wrote:
>
>>> Tested on gcc-trunk for arm-none-linux-gnueabi.
>>>
>>> OK to commit?
>>> 2015-06-16 James Lemke
>>>
>>> libgcc/config/arm/
>>> * lib1funcs.S (aeabi_idiv0, aeabi_ldiv0): Add CFI entries for
>>> Linux ARM
On Fri, Jun 19, 2015 at 7:04 PM, Charles Baylis
wrote:
> 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 t
On 24/06/15 02:00, Sandra Loosemore wrote:
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle this -- earlier, by rejecting renamings that
trunk.
Will apply to 5 after regression testing there and 4.9 after it unfreezes.
Ramana
2015-06-24 Ramana Radhakrishnan
PR target/63408
* config/arm/arm.c (vfp3_const_double_for_fract_bits): Disable
for negative numbers.
2015-06-24 Ramana Radhakrishnan
-24 Ramana Radhakrishnan
* gcc.target/arm/fixed_float_conversion.c: Skip for inappropriate
multilibs.
* gcc.target/arm/memset-inline-10.c: Likewise.
* gcc.target/arm/pr58784.c: Likewise.
* gcc.target/arm/pr59985.C: Likewise.
* gcc.target/arm/vfp-1
On 12/06/15 21:50, Abe Skolnik wrote:
Hi everybody!
In the current implementation of if conversion, loads and stores are
if-converted in a thread-unsafe way:
* loads were always executed, even when they should have not been.
Some source code could be rendered invalid due to null point
This fixes PR target/29693 by returning DWARF_FRAME_REGISTERS instead of
calling gcc_unreachable.
Applied to trunk after bootstrap and regression testing on armhf.
Ramana
2015-06-25 Ramana Radhakrishnan
PR target/29693
* config/arm/arm.c (arm_dbx_register_number): Return
Benedikt,
On 25/06/15 08:01, pins...@gmail.com wrote:
On Jun 18, 2015, at 5:04 AM, Benedikt Huber
wrote:
arch64 offers the instructions frsqrte and frsqrts, for rsqrt estimation and
a Newton-Raphson step, respectively.
There are ARMv8 implementations where this is faster than using fdiv
On Mon, Jun 22, 2015 at 5:56 PM, Alex Velenko wrote:
> On 20/05/15 21:14, Joseph Myers wrote:
>>
>> Again, the condition you propose to add doesn't make sense. arm_arch_X_ok
>> is only appropriate for tests using an explicit -march=X. Testing with
>> -march=armv7* should automatically skip this
amana Radhakrishnan
* config/arm/arm.c (arm_output_multireg_pop): Fix use of
TARGET_UNIFIED_ASM.
commit c085a69d4c1b9f9e43ef9655d1e88e7286ca3c2f
Author: Ramana Radhakrishnan
Date: Thu Jun 25 09:43:11 2015 +0100
Use TARGET_THUMB2 instead of TARGET_UNIFIED_ASM.
handle
As part of the work on PR66192 I promised a doc update at some point -
here's that - hopefully better late than never.
I also wonder if this is worth putting into the documentation in
addition to our release notes though I couldn't convince myself that
standards.texi was the right place for it
On Mon, Jun 22, 2015 at 10:48 AM, Matthew Wahab wrote:
> This is the ARM version of the patches to strengthen memory barriers for the
> __sync builtins on ARMv8 targets
> (https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01989.html).
>
> The problem is that the barriers generated for the __sync built
On Mon, Jun 22, 2015 at 10:50 AM, Matthew Wahab wrote:
> This is the ARM version of the patches to strengthen memory barriers for the
> __sync builtins on ARMv8 targets
> (https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01989.html).
>
> This patch changes the code generated for __sync_type_compare_a
On Mon, Jun 22, 2015 at 10:52 AM, Matthew Wahab wrote:
> This is the ARM version of the patches to strengthen memory barriers for the
> __sync builtins on ARMv8 targets
> (https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01989.html).
>
> This patch adds tests for the code generated by the ARM backend
On Wed, Jul 1, 2015 at 12:32 PM, Matthew Wahab
wrote:
> Hello,
>
> Tests I recently added for the code generated by the ARM backend for the
> __sync
> builtins had
>
> - 'do-require-effective-target', instead of the directive
> 'dg-require-effective-target' and
> - 'stlex' instead of 'strex' in
On Thu, Jul 2, 2015 at 7:34 PM, Sebastian Pop wrote:
> On Thu, Jul 2, 2015 at 1:17 PM, Tobias Grosser wrote:
>> On 07/02/2015 06:52 PM, Aditya Kumar wrote:
>>>
>>> gcc/ChangeLog:
>>>
>>> 2015-07-02 Aditya Kumar
>>> Sebastian Pop
>>>
>>> * graphite-sese-to-poly.c (rewrite
On 06/07/15 12:00, Alan Lawrence wrote:
> Eric Botcazou wrote:
>>> Technically this is incorrect since AGGREGATE_TYPE_P includes ARRAY_TYPE
>>> and ARRAY_TYPE doesn't have TYPE_FIELDS. I doubt we could reach that
>>> case though (unless there's a language that allows passing arrays by value).
>>
On 30/06/15 13:07, Christian Bruel wrote:
> Hi,
>
> A little bit of polishing around arm/thumb attribute_target emission and
> testing: Since the arch mode is emitted for each function, the file setting
> becomes useless or redundant.
>
> for example with attr_thumb.c:
>
> =>.arm
> =>
On 18/06/15 20:02, Eric Botcazou wrote:
>> Please mark this pattern with (set_attr "type" "multiple").
>
> Done.
>
>> While I suspect that stack probing is done before any insns with invalid
>> constants in the function, it would be better to model the length of
>> this insn so that the minipoo
On 06/07/15 17:38, Alan Lawrence wrote:
> Trying to push these now (svn!), patch 2 is going first.
>
> I realize my second iteration of patch 1/2, dropped the testcases from the
> first version. Okay to include those as per
> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00215.html ?
Yeah the
I haven't seen the patch yet but here are my thoughts on where this should be
going.
On 07/07/15 18:17, Alan Lawrence wrote:
> Kyrill Tkachov wrote:
>> On 07/07/15 17:34, Alan Lawrence wrote:
>>> Kyrill Tkachov wrote:
On 07/07/15 14:09, Kyrill Tkachov wrote:
> Hi Alan,
>
> On 07/
On 21/04/15 10:11, Kyrill Tkachov wrote:
> Hi all,
>
> This is the first of a series to clean up and simplify the arm rtx costs
> function.
> This patch initialises the cost to COSTS_N_INSNS (1) at the top and
> increments it when appropriate
> in the rest of the function. This makes it more s
401 - 500 of 1421 matches
Mail list logo
