Re: [PATCH 2/4][AArch64] Increase the loop peeling limit

On 15/12/15 23:34, Evandro Menezes wrote: > On 12/14/2015 05:26 AM, James Greenhalgh wrote: >> On Thu, Dec 03, 2015 at 03:07:43PM -0600, Evandro Menezes wrote: >>> On 11/20/2015 05:53 AM, James Greenhalgh wrote: On Thu, Nov 19, 2015 at 04:04:41PM -0600, Evandro Menezes wrote: > On

Re: [patch] ARM FreeBSD fix bootstrap

On 23/12/15 19:28, Andreas Tobler wrote: > On 23.12.15 11:22, Richard Earnshaw (lists) wrote: >> On 22/12/15 19:53, Andreas Tobler wrote: >>> Hi all, >>> >>> the commit for PR68617 broke boostrap on armv6*-*-freebsd*. >>> >>> We st

Re: [patch] ARM FreeBSD fix bootstrap

On 05/01/16 21:03, Andreas Tobler wrote: > On 05.01.16 11:32, Richard Earnshaw (lists) wrote: >> On 23/12/15 19:28, Andreas Tobler wrote: > >>> 2015-12-23 Andreas Tobler <andre...@gcc.gnu.org> >>> >>> * config/arm

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On 07/01/16 09:15, Kyrill Tkachov wrote: > > On 07/01/16 07:34, Thomas Preud'homme wrote: >> On Tuesday, January 05, 2016 10:47:38 AM Kyrill Tkachov wrote: >>> Hi Thomas, >> Hi Kyrill, >> diff --git a/gcc/testsuite/g++.dg/pr67989.C b/gcc/testsuite/g++.dg/pr67989.C index

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

On 05/01/16 10:47, Kyrill Tkachov wrote: > Hi Thomas, > > On 05/01/16 07:37, Thomas Preud'homme wrote: >> Hi, >> >> g++.dg/pr67989.C passes -march=armv4t to gcc when compiling which >> fails if >> RUNTESTFLAGS passes -mcpu or -march with a different value. This patch >> adds a >> dg-skip-if

Re: [patch] ARM FreeBSD fix bootstrap

On 22/12/15 19:53, Andreas Tobler wrote: > Hi all, > > the commit for PR68617 broke boostrap on armv6*-*-freebsd*. > > We still have unaligned_access = 0 on armv6 here on FreeBSD. > > The commit from the above PR overrides my SUBTARGET_OVERRIDE_OPTIONS I > called in arm_option_override. And it

Re: [ARM] Fix ICE on Ada code with -mbig-endian -mhard-float

On 21/12/15 16:24, Eric Botcazou wrote: > Hi, > > the attached Ada testcase triggers an ICE with -mbig-endian -mhard-float: > > eric@polaris:~/build/gcc/arm-linux-gnueabi> gcc/xgcc -Bgcc -S p.adb -I > gcc/ada/rts -mbig-endian -mhard-float > +===GNAT BUG

Re: [PATCH/AARCH64] Fix -mcpu/arch=native support for LSE

On 11/12/15 19:54, Andrew Pinski wrote: > Hi, > The Linux kernel calls lse as atomics in /proc/cpuinfo. We should > change aarch64-option-extensions.def to take that into account. > > OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions > and tested with -mcpu=native on

Re: [Patch testsuite] Skip gcc.dg/ifcvt-4.c for targets on which it may not work

On 21/12/15 19:38, Jeff Law wrote: > On 12/18/2015 02:55 AM, James Greenhalgh wrote: >> This is a multi-part message in MIME format. >> --2.2.0.1.gd394abb.dirty >> Content-Type: text/plain; charset=UTF-8; format=fixed >> Content-Transfer-Encoding: 8bit >> >> >> Hi, >> >> PR68232 is a

Re: [trans-mem, aa64, arm, ppc, s390] Fixing PR68964

On 12/01/16 16:53, Richard Henderson wrote: > The problem in this PR is that we never got around to flushing out the vector > support for transactions for anything but x86. My goal here is to make this > as > generic as possible, so that it should Just Work with existing vector support > in the

Re: [4.9][PR69082]Backport "[PATCH][ARM]Tighten the conditions for arm_movw, arm_movt"

On 12/01/16 15:31, Renlin Li wrote: > Hi all, > > Here I backport r227129 to branch 4.9 to fix exactly the same issue > reported in PR69082. > It's been already committed on trunk and backportted to branch 5. > > > I have quoted the original message for the explanation. > The patch applies to

Re: [trans-mem, aa64, arm, ppc, s390] Fixing PR68964

On 12/01/16 17:16, Richard Earnshaw (lists) wrote: > On 12/01/16 16:53, Richard Henderson wrote: >> The problem in this PR is that we never got around to flushing out the vector >> support for transactions for anything but x86. My goal here is to make this >> as >&

Re: [AArch64] Give some new costs for Cortex-A57 floating-point operations

On 03/06/16 09:35, James Greenhalgh wrote: > > Hi, > > This patch rebases the floating-point cost table for Cortex-A57 to be > relative to the cost of a floating-point move. This in response to this > feedback from Richard Sandiford [2] on Ramana's patch to calls.c [1] from > 2014: > > I

Re: [AArch64] Give some new costs for Cortex-A53 floating-point operations

On 20/06/16 14:57, James Greenhalgh wrote: > > Hi, > > As recently done for Cortex-A57 [1], this patch rebases the floating-point > cost table for Cortex-A53 to be relative to the cost of a floating-point move. > I wrote a little more on the justification for doing this in the other patch, > but

Re: [Patch AArch64] Fixup to fcvt patterns added in r237200

On 10/06/16 13:29, James Greenhalgh wrote: > > Hi, > > My autotester picked up some issues with the vcvt{ds}_n_* intrinsics > added in r237200. > > The iterators in this pattern do not resolve, as they have not been > explicitly tied to the mode iterator (rather than the code iterator) > used

Re: [Patch AArch64] Add some more missing intrinsics

On 13/06/16 17:31, James Greenhalgh wrote: > > Hi, > > Inspired by Jiong's recent work, here are some more missing intrinsics, > and a smoke test for each of them. > > This patch covers: > > vcvt_n_f64_s64 > vcvt_n_f64_u64 > vcvt_n_s64_f64 > vcvt_n_u64_f64 > vcvt_f64_s64 >

Re: [PATCH] Fix PR68707

On 08/01/16 11:45, Richard Biener wrote: > On Fri, 8 Jan 2016, Alan Lawrence wrote: > >> Here's an alternative patch, using the hunk from >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68707#c16, which 'improves' >> (heh, >> we think) on the previous by allowing SLP to proceed where the loads

Re: [aarch64] Fix target/69176

> +(define_constraint "Upl" > + "A constraint that matches two uses of add instructions." That's not a particularly helpful description for external users of the compiler. I think that either needs to be sufficiently precise that people who understand the ISA but not the guts of GCC can use it,

Re: [PATCH ARM] RFC: PR69770 -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg

On 12/02/16 14:56, Charles Baylis wrote: > When compiling with -mlong-calls and -pg, calls to the __gnu_mcount_nc > function are not generated as long calls. > > This is encountered when building an allyesconfig Linux kernel because > the Linux build system generates very large sections by

[WWWDocs] Deprecate support for non-thumb ARM devices

After discussion with the ARM port maintainers we have decided that now is probably the right time to deprecate support for versions of the ARM Architecture prior to ARMv4t. This will allow us to clean up some of the code base going forwards by being able to assume: - Presence of half-word data

Re: [PATCH][ARM] Add initial support for the Cortex-A32

On 24/02/16 10:49, Kyrill Tkachov wrote: > Hi all, > > This patch adds initial support for the Cortex-A32 core. > It is an ARMv8-A core and this patch enables the -mcpu=cortex-a32 and > -mtune=cortex-a32 options. > > The initial tunings are set to the same parameters as for Cortex-A35. > >

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 24/02/16 17:38, Joseph Myers wrote: > On Wed, 24 Feb 2016, Richard Earnshaw (lists) wrote: > >> After discussion with the ARM port maintainers we have decided that now >> is probably the right time to deprecate support for versions of the ARM >> Architecture prior to

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 25/02/16 13:32, Stefan Ring wrote: > On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> The point is to permit the compiler to use interworking compatible >> sequences of code when generating ARM code, not to force us

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 25/02/16 14:15, David Brown wrote: > On 25/02/16 14:32, Stefan Ring wrote: >> On Thu, Feb 25, 2016 at 10:20 AM, Richard Earnshaw (lists) >> <richard.earns...@arm.com> wrote: >>> The point is to permit the compiler to use interworking compatible >>> seq

Re: [PATCH][ARM] PR target/70008

On 29/02/16 11:21, Michael Collison wrote: > > > On 2/29/2016 4:06 AM, Kyrill Tkachov wrote: >> Hi Michael, >> >> On 29/02/16 04:47, Michael Collison wrote: >>> This patches address PR 70008, where a reverse subtract with carry >>> instruction can be generated in thumb2 mode. It was tested with

Re: [PATCH][ARM][wwwdocs] Mention Cortex-A32 and Cortex-A35 support in changes.html for GCC 6

On 26/02/16 14:25, Kyrill Tkachov wrote: > Hi all, > > This patch adds a note to changes.html about the added support for > Cortex-A32 and Cortex-A35. > > Ok to commit? > OK. R. > Thanks, > Kyrill > > wwwdocs-a32-a35.patch > > > Index: htdocs/gcc-6/changes.html >

Re: [WWWDocs] Deprecate support for non-thumb ARM devices

On 24/02/16 13:59, Richard Earnshaw (lists) wrote: > After discussion with the ARM port maintainers we have decided that now > is probably the right time to deprecate support for versions of the ARM > Architecture prior to ARMv4t. This will allow us to clean up some of > the cod

Re: [PATCH] Fix aarch64 bootstrap (pr69416)

On 22/01/16 17:07, Richard Henderson wrote: > The bare CONST_INT inside the CCmode IF_THEN_ELSE is causing combine to > make incorrect simplifications. At this stage it feels safer to wrap > the CONST_INT inside of an UNSPEC than make more generic changes to > combine. > > But we should

Re: [PATCH][ARM] PR target/70566 Check that condition register is dead in tst-imm -> lsls-imm Thumb2 peepholes

On 07/04/16 15:51, Kyrill Tkachov wrote: > Hi all, > > In this wrong-code PR we have a Thumb2 peephole transforming: > tstr3, #2 > bne.L3 > beq.L6 > > into: > lslsr3, r3, #30 // LSLS is shorter than TST in Thumb2 > bmi.L3 > beq.L6 > > that is,

Re: [PATCH][ARM] Add deprecation warning on pre-v4t architecture revisions

On 01/03/16 16:17, Kyrill Tkachov wrote: > Hi all, > > For GCC 6 we want to deprecate architecture revisions prior to ARMv4T. > This patch implements this by documenting the deprecation in invoke.texi > and adding > a warning whenever the user specifies an -march or -mcpu option that > selects

Re: [PATCH][ARM][RFC] PR target/65578 Fix gcc.dg/torture/stackalign/builtin-apply-4.c for single-precision fpus

On 09/02/16 17:21, Kyrill Tkachov wrote: > Hi all, > > In this wrong-code PR the builtin-apply-4.c test fails with -flto but > only when targeting an fpu > with only single-precision capabilities. > > bar is a function returing a double. For non-LTO compilation the caller > of bar reads the

Re: [PATCH][ARM] PR target/70566 Check that condition register is dead in tst-imm -> lsls-imm Thumb2 peepholes

On 11/04/16 14:27, Kyrill Tkachov wrote: > > On 08/04/16 10:30, Richard Earnshaw (lists) wrote: >> On 07/04/16 15:51, Kyrill Tkachov wrote: >>> Hi all, >>> >>> In this wrong-code PR we have a Thumb2 peephole transforming: >>> tst

Re: [Patch AArch64 0/3] Fix PR70133

On 06/04/16 11:10, James Greenhalgh wrote: > Hi, > > This patch set fixes PR70133, which is a bug in the way we handle extension > strings after using -march or -mcpu=native. In investigating this, I found > other bugs in the way we communicate architceture intention between the > compiler and

Re: [AArch64] Disable pcrelative_literal_loads with fix-cortex-a53-843419

On 14/03/16 15:34, Christophe Lyon wrote: > On 10 March 2016 at 14:24, James Greenhalgh wrote: >> On Thu, Mar 10, 2016 at 01:37:50PM +0100, Christophe Lyon wrote: >>> On 10 March 2016 at 12:43, James Greenhalgh >>> wrote: On Tue, Jan 26,

Re: [PATCH][ARM] PR target/70008

hat's something like: register_operand (op) || (TARGET_ARM && arm_immediate_operand (op)) R. > On 02/29/2016 08:29 AM, Richard Earnshaw (lists) wrote: >> On 29/02/16 11:21, Michael Collison wrote: >>> >>> On 2/29/2016 4:06 AM, Kyrill Tkachov wrote: >>>>

Re: [PATCH] Fix PR69951

On 01/03/16 10:49, Richard Biener wrote: > On Tue, 1 Mar 2016, Ramana Radhakrishnan wrote: > >> >> >> On 01/03/16 09:54, Richard Biener wrote: >>> On Tue, 1 Mar 2016, James Greenhalgh wrote: >>> On Tue, Mar 01, 2016 at 10:21:27AM +0100, Richard Biener wrote: > On Mon, 29 Feb 2016, James

Re: [PATCH][ARM] PR target/70014

On 01/03/16 17:33, Michael Collison wrote: > This patches addresses PR 70014, where the predicates and operand do not > match and could cause problems with the register allocator. Tested > successfully on > > arm-none-linux-gnueabi > arm-none-linux-gnuabihf > armeb-none-linux-gnuabihf >

Re: [PATCH][ARM] Add mode to probe_stack set operands

On 03/05/16 12:27, Kyrill Tkachov wrote: > Hi all, > > When building the arm backend genrecog complains that the probe_stack > set expression > doesn't specify any modes. This patch adds the SI mode annotation and > fixes the warning > > Bootstrapped and tested on arm-none-linux-gnueabihf. > >

Re: [patch] Get rid of stack trampolines for nested functions

On 25/07/16 14:25, Eric Botcazou wrote: >> If I understand how this is supposed to work then this is not >> future-proof against changes to the architecture. The bottom two bits >> in both AArch32 (arm) and AArch64 are reserved for future use by the >> architecture; they must not be used by

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

On 25/07/16 10:34, Jiong Wang wrote: > On 21/07/16 11:08, Richard Earnshaw (lists) wrote: >> On 20/07/16 16:02, Jiong Wang wrote: >>> Richard, >>>Thanks for the review, yes, I believe using aarch64_add_constant is >>> unconditionally >>> safe

Re: [patch] Get rid of stack trampolines for nested functions

On 29/06/16 23:08, Eric Botcazou wrote: > Index: config/aarch64/aarch64.h > === > --- config/aarch64/aarch64.h (revision 237789) > +++ config/aarch64/aarch64.h (working copy) > @@ -779,6 +779,9 @@ typedef struct > correctly. */

Re: [PATCH][AArch64] Allow multiple-of-8 immediate offsets for TImode LDP/STP

On 13/07/16 17:14, Kyrill Tkachov wrote: > Hi all, > > The most common way to load and store TImode value in aarch64 is to > perform an LDP/STP of two X-registers. > This is the *movti_aarch64 pattern in aarch64.md. > There is a bug in the logic in aarch64_classify_address where it > validates

Re: [AARCH64/PATCH] update vulcan L1 cacheline size

On 01/08/16 10:40, Virendra Pathak wrote: > Hi gcc-patches group, > > Please find the patch for updating vulcan L1 cacheline size. > > Tested the patch with compiling cross aarch64-linux-gcc, > bootstrapped native aarch64-unknown-linux-gnu and > run gcc regression. > > Kindly review and merge

Re: [PATCH][AArch64] Optimize prolog/epilog

On 29/07/16 12:49, Wilco Dijkstra wrote: > This patch optimizes the prolog and epilog code to reduce the number of > instructions and avoid multiple writes to SP. The key idea is that epilogs > are almost exact reverses of prologs, and thus all the decisions only need > to be taken once. The

Re: [PATCH][AArch64] Cleanup frame push/pop code

On 26/07/16 11:08, Wilco Dijkstra wrote: > This patch improves the readability of the prolog and epilog code by moving > some > code into separate functions. There is no difference in generated code. > > OK for commit? > > ChangeLog: > 2016-07-26 Wilco Dijkstra > > gcc/

Re: [PATCH/AARCH64] Add ThunderX vector cost model

On 03/08/16 23:42, Andrew Pinski wrote: > Hi, > This patch adds to the thunderx model, the vector cost model. I > benchmarked this on SPEC CPU INT 2006 and got a small speed up. I > have a few more cost model patches that I am going upstream but they > are going to be split up. > > OK?

Re: [PATCH][AArch64] Add legitimize_address_displacement hook

On 04/08/16 12:00, Wilco Dijkstra wrote: > This patch adds legitimize_address_displacement hook so that stack accesses > with large offsets are split into a more efficient sequence. Byte and > halfword > accesses use a 4KB range, wider accesses use a 16KB range to maximise the > available

Re: Implement -Wswitch-fallthrough: aarch64 + arm

Where the comments just say "Fall through", or equivalent, and there's no other explanation I think those comments are now redundant and should be removed. So remove: /* Fall through. */ but keep things like: /* Fall through - if the lane index isn't a constant then

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

On 20/07/16 16:02, Jiong Wang wrote: > On 20/07/16 15:18, Richard Earnshaw (lists) wrote: >> On 20/07/16 14:03, Jiong Wang wrote: >>> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue >>> are doing exactly what's aarch64_add_constant offered

Re: [PATCH 1/3][AArch64] Improve zero extend

On 19/07/16 16:30, Wilco Dijkstra wrote: > This patchset improves zero extend costs and code generation. > > When zero extending a 32-bit register, we emit a "mov", but currently > report the cost of the "mov" incorrectly. > > In terms of speed, we currently say the cost is that of an extend >

Re: [PATCH 2/3][AArch64] Improve zero extend

On 19/07/16 16:31, Wilco Dijkstra wrote: > When zero extending a 32-bit value to 64 bits, there should always be a > SET operation on the outside, according to the patterns in aarch64.md. > However, the mid-end can also ask for the cost of a made-up instruction, > where the zero-extend is part of

Re: [PATCH 3/3][AArch64] Improve zero extend

On 19/07/16 16:32, Wilco Dijkstra wrote: > On AArch64 the UXTB and UXTH instructions are aliases of UBFM, > which does a shift as part of its operation. An AND immediate is a > simpler operation, and might be faster on some implementations, so it is > better to emit this this instead of UBFM. > >

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

On 20/07/16 14:03, Jiong Wang wrote: > Those stack adjustment sequences inside aarch64_expand_prologue/epilogue > are doing exactly what's aarch64_add_constant offered, except they also > need to be aware of dwarf generation. > > This patch teach existed aarch64_add_constant about dwarf

Re: [AArch64][1/3] Migrate aarch64_add_constant to new interface & kill aarch64_build_constant

On 20/07/16 14:02, Jiong Wang wrote: > Currently aarch64_add_constant is using aarch64_build_constant to move > an immediate into the destination register. > > It has considered the following situations: > > * immediate can fit into bitmask pattern that only needs single > instruction. >

Re: [PATCH 2/3][AArch64] Improve zero extend

On 20/07/16 14:40, Wilco Dijkstra wrote: > Richard Earnshaw wrote: >> Why does combine care what the cost is if the instruction isn't valid? > > No idea. Combine does lots of odd things that don't make sense to me. > Unfortunately the costs we give for cases like this need to be accurate or >

Re: [AArch64][2/3] Optimize aarch64_add_constant to generate better addition sequences

On 20/07/16 14:02, Jiong Wang wrote: > This patch optimize immediate addition sequences generated by > aarch64_add_constant. > > The current addition sequences generated are: > > * If immediate fit into unsigned 12bit range, generate single add/sub. > * Otherwise if it fit into unsigned

Re: [PATCH 2/3][AArch64] Improve zero extend

On 20/07/16 14:08, Wilco Dijkstra wrote: > Richard Earnshaw wrote: >> I'm not sure about this, while rtx_cost is called recursively as it >> walks the RTL, I'd normally expect the outer levels of the recursion to >> catch the cases where zero-extend is folded into a more complex >> operation.

Re: [AArch64][3/3] Migrate aarch64_expand_prologue/epilogue to aarch64_add_constant

On 20/07/16 16:02, Jiong Wang wrote: > On 20/07/16 15:18, Richard Earnshaw (lists) wrote: >> On 20/07/16 14:03, Jiong Wang wrote: >>> Those stack adjustment sequences inside aarch64_expand_prologue/epilogue >>> are doing exactly what's aarch64_add_constant offered

Re: [PATCH 2/3][AArch64] Improve zero extend

On 20/07/16 16:28, Wilco Dijkstra wrote: > Richard Earnshaw wrote: >> Both of which look reasonable to me. > > Yes the code we generate for these examples is fine, I don't believe this > example ever went bad. It's just the cost calculation that is incorrect with > the outer check. > > Wilco >

Re: [PATCH][ARM] Fix gcc.target/arm/builtin-bswap16-1.c

On 03/06/16 09:30, Kyrill Tkachov wrote: > Hi all, > > The test gcc.target/arm/builtin-bswap16-1.c refuses to compile when > testing a toolchain configured with > --with-mode=thumb --with-float=hard and an architecture that supports > Thumb2. > This is because the test explicitly sets the -march

Re: [AArch64] ARMv8.2 command line and feature macros support

On 29/06/16 09:43, James Greenhalgh wrote: > On Mon, Jun 27, 2016 at 03:58:00PM +0100, Jiong Wang wrote: >> On 07/06/16 09:46, Jiong Wang wrote: >>> 2016-06-07 Matthew Wahab >>>Jiong Wang >>> >>>* config/aarch64/aarch64-arches.def:

Re: [PATCH][AArch64] Improve Cortex-A53 integer scheduler

On 05/07/16 16:00, Wilco Dijkstra wrote: > This patch improves the accuracy of the Cortex-A53 integer scheduler, > resulting in performance gains across a wide range of benchmarks. > > OK for commit? > OK. R. > ChangeLog: > 2016-07-05 Wilco Dijkstra > > *

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 04/08/16 22:16, Bernd Edlinger wrote: > Hi, > > this patch introduces a new target hook that allows the target's > INITIAL_ELIMINATION_OFFSET function to use cached values instead of > re-computing the frame layout every time. > > I have updated the documentation a bit and hope it is clearer

Re: [PATCH][AArch64] Improve stack adjustment

On 04/08/16 16:56, Richard Earnshaw (lists) wrote: > On 04/08/16 12:06, Wilco Dijkstra wrote: >> Improve stack adjustment by reusing a temporary move immediate >> from the epilog if the register is still valid in the epilog. This generates >> smaller code for leaf functio

Re: [AArch64] Handle HFAs of float16 types properly

On 05/08/16 15:17, James Greenhalgh wrote: > On Fri, Aug 05, 2016 at 11:15:24AM +0100, James Greenhalgh wrote: >> On Fri, Aug 05, 2016 at 11:00:39AM +0100, Yao Qi wrote: >>> On Tue, Jul 26, 2016 at 2:55 PM, James Greenhalgh >>> wrote: OK? As this is an ABI

Re: [PATCH, ARM] Add a new target hook to compute the frame layout

On 05/08/16 13:49, Bernd Edlinger wrote: > On 08/05/16 11:29, Richard Earnshaw (lists) wrote: >> On 04/08/16 22:16, Bernd Edlinger wrote: >>> Hi, >>> >>> this patch introduces a new target hook that allows the target's >>> INITIAL_ELIMINATION_OFFSET fu

Re: [PATCH/AARCH64] Improve ThunderX code generation slightly with load/store pair

On 08/08/16 18:48, Andrew Pinski wrote: > On Fri, Aug 5, 2016 at 12:18 AM, Andrew Pinski wrote: >> Hi, >> On ThunderX, load (and store) pair that does a pair of two word >> (32bits) load/stores is slower in some cases than doing two >> load/stores. For some internal

Re: [Patch AArch64] Fix PR target/63874

On 31/03/16 14:11, 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 PC relative > relocations. > > However if you

Re: [PATCH][AArch64][1/2] Add support INS (element) instruction to copy lanes between vectors

On 07/06/16 17:56, Kyrill Tkachov wrote: > Hi all, > > This patch addresses an deficiency we have in handling vector > lane-to-lane moves in the AArch64 backend. > Generally we can use the INS (element) instruction but, as a user > complains in

Re: [PATCH][AArch64] Canonicalize Cortex core tunings

On 29/06/16 18:03, Wilco Dijkstra wrote: > This patch sets the branch cost to the same most optimal setting for all > Cortex cores, > reducing codesize and improving performance due to using more CSEL > instructions. > Set the autoprefetcher model in Cortex-A72 to weak like the others. Enable

Re: [PATCH][ARM] Delete thumb_reload_in_h

On 10/06/16 15:55, Kyrill Tkachov wrote: > Hi all, > > This function just ICEs and isn't actually called from anywhere. > It was introduced back in 2000 as part of a large merge introducing > Thumb support > and was aborting even then. I don't think having it around is of any > benefit. > >

Re: [PATCH][AArch64] Fix some scan-assembler tests for -mabi=ilp32

On 29/06/16 11:40, Kyrill Tkachov wrote: > Hi all, > > I notice these scan-assembler tests fail when testing -mabi=ilp32 > because the 64-bit operation that they > expect doesn't happen on the 32-bit long types in that configuration. > > The easy fix is to change the 'long' types to be 'long

Re: [PATCH][AArch64] Fix some scan-assembler tests for -mabi=ilp32

On 29/06/16 11:47, James Greenhalgh wrote: > On Wed, Jun 29, 2016 at 11:40:13AM +0100, Kyrill Tkachov wrote: >> Hi all, >> >> I notice these scan-assembler tests fail when testing -mabi=ilp32 because the >> 64-bit operation that they expect doesn't happen on the 32-bit long types in >> that

Re: [PATCH] [GCC] Don't use section anchors for declarations that don't fit in a single anchor range

On 17/08/16 09:23, Richard Biener wrote: > On Tue, Aug 16, 2016 at 6:06 PM, Jeff Law wrote: >> On 08/16/2016 08:01 AM, Tamar Christina wrote: >>> >>> >>> Hi All, >>> >>> This patch turns off the usage of section anchors for >>> declarations that do not fit in a single anchor

Re: [PATCH/VECT/AARCH64] Improve cost model for ThunderX2 CN99xx

On 31/01/17 22:34, Andrew Pinski wrote: > On Sat, Jan 28, 2017 at 12:34 PM, Andrew Pinski wrote: >> Hi, >> On some (most) AARCH64 cores, it is not always profitable to >> vectorize some integer loops. This patch does two things (I can split >> it into different patches if

Re: Fix profile updating in ifcombine

On 07/02/17 08:37, Christophe Lyon wrote: > Hi, > > > On 6 February 2017 at 17:56, Richard Earnshaw (lists) > <richard.earns...@arm.com> wrote: >> On 06/02/17 15:54, Jiong Wang wrote: >>> On 06/02/17 15:26, Jan Hubicka wrote: >>>> I think it i

Re: Fix profile updating in ifcombine

On 06/02/17 15:54, Jiong Wang wrote: > On 06/02/17 15:26, Jan Hubicka wrote: >> I think it is not a regression, just the testcase if fragile and >> depends on outcome >> of ifcombine. It seems it was updated several time in the past. I am >> not quite >> sure what the test is testing. > > They

Re: [ARM] Fix broken sibcall with longcall, APCS frame and VFP

On 20/01/17 18:13, Eric Botcazou wrote: >> This seems to have fallen through a crack. Did you get a chance to try >> either of these suggestions? > > So just: > > /* { dg-do run } */ > /* { dg-options "-mapcs-frame -O -foptimize-sibling-calls > -ffunction-sections" > } */ > > in the header

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 21/01/17 20:15, Andreas Tobler wrote: > On 21.01.17 00:42, Jakub Jelinek wrote: >> On Fri, Jan 20, 2017 at 01:37:13PM -0700, Jeff Law wrote: > Which is best will depend on what the front/mid ends might have > done to > apply the documented limit. Here I know not enough to

[PATCH][ARM] Fix PR79239 - unrecognized insn after pragma gcc pop_options

It turns out that because the compiler uses a hash table to save the cl_target_option structures it is unsafe to modify the result of build_target_option_node() (doing so will cause the hash lookup to fail). This PR was due to not properly understanding this limitation. The fix is to create

[arm] PR target/79260: Fix header installation for plugins

The recent changes to the header infrastructure for ARM targets broke building of plugins due to missing headers. Patch below, tested on a cross build plus visual examination of the install infrastructure. PR target/79260 * config.gcc (arm*-*-*): Add arm/arm-flags.h and arm/arm-isa.h to

Re: [PATCH/VECT/AARCH64] Improve cost model for ThunderX2 CN99xx

On 28/01/17 20:34, Andrew Pinski wrote: > Hi, > On some (most) AARCH64 cores, it is not always profitable to > vectorize some integer loops. This patch does two things (I can split > it into different patches if needed). > 1) It splits the aarch64 back-end's vector cost model's vector and >

Re: RFA: Patch for ARM PR77770

On 25/01/17 10:28, Nick Clifton wrote: > Hi Richard, Hi Ramana, > > The patch below is a simple fix for PR0. I am not really > expecting you to agree with it, but I thought that it was worth > posting so that this PR could be looked at again and maybe a better > patch found. (Plus I

Re: [PATCH TEST]Remove xfail for gcc.dg/vect/vect-24.c on ARM targets

On 24/01/17 17:22, Bin Cheng wrote: > Hi, > Test gcc.dg/vect/vect-24.c starts passing after my vectorizer changes, but > not on all targets. For x86_64, looks like other passes still mess up the IR > and prevent it from being vectorized. This patch removes xfail for ARM > targets. > Test

Re: [PATCH][ARM] PR target/79145 Fix xordi3 expander for immediate operands in iWMMXt

On 25/01/17 10:58, Kyrill Tkachov wrote: > Hi all, > > We're hitting an ICE when expanding a DImode xor with an immediate on > TARGET_IWMMXT: > (insn 6 5 7 2 (set (reg:DI 111 [ t1.1_3 ]) > (xor:DI (reg:DI 110 [ t1.0_2 ]) > (const_int 85 [0x55]))) ./z32.c:13 -1 > (nil)) >

Re: Improve things for PR71724, in combine/if_then_else_cond

On 25/01/17 09:29, Christophe Lyon wrote: > On 25 January 2017 at 10:18, Kyrill Tkachov > wrote: >> >> On 25/01/17 08:53, Christophe Lyon wrote: >>> >>> On 24 January 2017 at 18:15, Bernd Schmidt wrote: On 01/24/2017 06:03 PM,

Re: [PATCH AARCH64]XFAIL gcc.target/aarch64/ldp_vec_64_1.c

On 25/01/17 16:49, Bin Cheng wrote: > Hi, > Test gcc.target/aarch64/ldp_vec_64_1.c because we don't choose [base+offset] > addressing mode in IVOPT > on AArch64. Given auto-increment addressing mode is disabled in IVOPT on > AArch64, we can't really test > the addressing mode. I may try to

Re: [PATCH][ARM] PR target/71270 fix neon_valid_immediate for big-endian

On 06/01/17 11:54, Kyrill Tkachov wrote: > Hi all, > > In this wrong-code issue the RTL tries to load a const_vector: > (const_vector:V8QI [ > (const_int 1 [0x1]) > (const_int 0 [0]) > (const_int 1 [0x1]) > (const_int 0 [0]) > (const_int 1 [0x1]) >

Re: [RFC] fix bootstrap on aarch64-*-freebsd and probably others

On 20/01/17 19:56, Andreas Tobler wrote: > On 20.01.17 17:12, Richard Earnshaw (lists) wrote: >> On 19/01/17 06:38, Andreas Tobler wrote: >>> On 19.01.17 00:33, Jeff Law wrote: >>>> On 01/18/2017 11:43 AM, Andreas Tobler wrote: >>>>> Hi all, >>&

[PATCH, wwwdocs] Update list of ARM cpus in readings.html

The list of ARM CPUs in readings.html is now looking rather dated. This patch updates the list to refer to the most commonly available parts (or at least, the product families by which they are known). Committed. R. ? backends.html~ ? index.html.~1.866.~ ? readings.html.~1.260.~ ?

Re: [PATCH 1/5] Handle WORD_REGISTER_OPERATIONS when reloading (subreg(reg))

On 21/02/17 19:53, Matthew Fortune wrote: > Eric Botcazou writes: >>> Agreed. I don't think things like WORD_MODE_OPERATIONS should change >>> rtl semantics, just optimisation decisions. > > Sorry, I did cover two topics in one email. My point was about whether >

[PATCH, wwwdocs] Update AArch64 entry in readings.html

This patch tweaks the wording in the entry for AArch64 and also adds a Manufacturer: entry similar to that for ARM. Committed. R. Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.261

Re: [ARM] Enable descriptors for nested functions in Ada

On 13/11/16 22:31, Eric Botcazou wrote: > Similarly to x86, PowerPC and SPARC, this enables the use of custom run-time > descriptors in Ada, thus eliminating the need for trampolines and executable > stack in presence of pointers to nested functions. > > This still uses bit 1 for the run-time

Re: [PATCH] Fix exception handling for ILP32 aarch64

On 07/02/17 23:11, Steve Ellcey wrote: > This patch was submitted last year by Andrew Pinski, this is a > resubmit/ping of that patch. > > https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01726.html > > During the initial submittal James Greenhalgh asked if this was an ABI change. > I do not

Re: [PATCH][AArch64] PR rtl-optimization/68664 Implement TARGET_SCHED_CAN_SPECULATE_INSN hook

On 14/02/17 10:08, Kyrill Tkachov wrote: > Hi all, > > Following up from Segher's patch here is the aarch64 implementation of > the new hook. > It forbids speculation of the integer and floating-point division > instructions as well as the > square-root instructions. > > With this patch the

Re: [PATCH][ARM] PR rtl-optimization/68664 Implement TARGET_SCHED_CAN_SPECULATE_INSN hook

On 14/02/17 10:11, Kyrill Tkachov wrote: > Hi all, > > And this is the arm implementation of the hook. It is the same as the > aarch64 one since the two ports > share their instruction types for scheduling purposes. > > Bootstrapped and tested on arm-none-linux-gnueabihf. > > Ok for trunk? > >

Re: [PATCH v5] add -fprolog-pad=N,M option

On 15/02/17 11:12, Marek Polacek wrote: > On Wed, Feb 15, 2017 at 11:01:16AM +0000, Richard Earnshaw (lists) wrote: >> On 13/01/17 12:19, Torsten Duwe wrote: >>> Changes since v4: hopefully addressed all of Sandra's requests >>> and suggestions concerning the doc

Re: [PATCH v5] add -fprolog-pad=N,M option

On 13/01/17 12:19, Torsten Duwe wrote: > Changes since v4: hopefully addressed all of Sandra's requests > and suggestions concerning the documentation snippets, thanks > for the feedback. If it still isn't clear, feel free to rephrase > -- I'm a programmer, not a technical writer. > Generally,

Re: [PATCH, wwwdocs/ARM] Deprecate ARMv5 and ARMv5E support

On 15/02/17 11:23, Thomas Preudhomme wrote: > Hi, > > ARMv5 and ARMv5E architectures have no known implementation. I therefore > suggest that we deprecate these architectures. ARMv5T, ARMv5TE and > ARMv5TEJ would remain supported though. > > Is this ok to commit? > > Best regards, > > Thomas >

Re: [PATCH/AARCH64] Change -mcpu=thunderx2t99 's -mcpu=native support

On 06/02/17 06:20, Andrew Pinski wrote: > Hi, > When I implemented the -mcpu=thunderx2t99 I did not have the Cavium > partno for ThunderX CN99xx, only the original part no. This patch > adds the new part no for the future versions of the chip. > > OK? Bootstrapped and tested on

  1   2   3   4   5   6   7   8   9   10   >