On 8/15/19 12:06 PM, Aldy Hernandez wrote:
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernan
> -Original Message-
> From: H.J. Lu [mailto:hjl.to...@gmail.com]
> Sent: Friday, August 16, 2019 6:02 AM
> To: Jeff Law
> Cc: Cui, Lili ; Uros Bizjak ; GCC
> Patches ; Zhang, Annita
> ; Xiao, Wei3 ; Liu, Hongtao
> ; Wang, Hongyu ;
> Castillo, Jason M
> Subject: Re: Add TIGERLAKE and CO
- -fsanitize=kernel-address will call targetm.asan_shadow_offset ()
at asan_shadow_offset, so it will crash if TARGET_ASAN_SHADOW_OFFSET
is not implemented, that's mean -fsanitize=kernel-address is not
supported for target without TARGET_ASAN_SHADOW_OFFSET implementation.
gcc/ChangeLog:
On Thu, Aug 15, 2019 at 01:24:07PM -0500, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Aug 15, 2019 at 01:35:10PM +0930, Alan Modra wrote:
> > Supporting TLS for -mpcrel turns out to be relatively simple, in part
> > due to deciding that !TARGET_TLS_MARKERS with -mpcrel is silly. No
> > assembler
This is a proposed patch to libiberty, with an accompanying patch to GCC.
The purpose of this patch is to make it possible for Windows-hosted
toolchains to have the ability to control whether Canonicalized
filenames are converted to all lower-case.
Most Windows users are not affected by this be
On 8/14/19 5:06 PM, Michael Meissner wrote:
> This patch adds prefixed memory support to all offsettable instructions.
>
> Unlike previous versions of the patch, this patch combines all of the
> modifications for addressing to one patch. Previously, I had 3 separate
> patches (one for PADDI, one f
Hi Mike, just a couple points from me...
On 8/15/19 4:19 PM, Michael Meissner wrote:
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 274172)
> +++ gcc/config/rs6000/rs6000.c(workin
On 8/6/19 5:51 AM, Richard Earnshaw (lists) wrote:
On 18/07/2019 18:18, James Greenhalgh wrote:
On Mon, Jun 10, 2019 at 06:21:05PM +0100, Sylvia Taylor wrote:
Greetings,
This patch adds the intrinsic functions for:
- vld1__x4
- vst1__x4
- vld1q__x4
- vst1q__x4
Bootstrapped and tested on aarch
On 8/15/19 5:34 PM, Marek Polacek wrote:
On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek wrote:
On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
On 8/6/19 3:20 PM, Marek Polacek wrote:
On Mon, Aug 05, 2019 at 03:54:19
Hi Mike,
On Thu, Aug 15, 2019 at 05:19:16PM -0400, Michael Meissner wrote:
> -;; Return true if the operand is a pc-relative address.
> +;; Return true if the operand is a pc-relative address to a local symbol.
The pcrel_addr_p comment says it is *not* just for local symbols. So
which is it?
Ha
Hi Janne,
The patch itself looks Ok. One worry, are you introducing an
O(N**2)(?) algorithm (looping over all symbols for every symbol?), and
does this cause performance issues when compiling some gigantic F77
project?
This is a single pass over the code, so O(N) for the code size.
The lookup
Hi Richard.
> . Dynamic stack allocation (alloca and VLAs) is achieved by using what
> otherwise would be a perfectly normal general register, %r9, as a
> pseudo stack pointer. This has the disadvantage of making the
> register "fixed" and therefore not available for gener
On Wed, Aug 14, 2019 at 11:04 AM Jeff Law wrote:
>
> On 8/14/19 1:38 AM, Cui, Lili wrote:
> > Resend this mail for GCC Patches rejected my message, thanks.
> >
> > -Original Message-
> >
> > Hi Uros and all:
> >
> > This patch is about to add TIGERLAKE and COOPERLAKE to GCC.
> > TIGERLAKE
My previous patch for 64372 was incomplete: it only stopped making the
non-throw argument into an rvalue, lvalue_kind still considered the ?:
expression to be an rvalue, leaving us worse than before.
For GCC 9 I lean toward reverting the earlier patch rather than applying this
one and thus changin
On Wed, Aug 14, 2019 at 02:50:13PM -0400, Jason Merrill wrote:
> On Thu, Aug 8, 2019 at 3:25 PM Marek Polacek wrote:
> >
> > On Thu, Aug 08, 2019 at 11:06:17AM -0400, Jason Merrill wrote:
> > > On 8/6/19 3:20 PM, Marek Polacek wrote:
> > > > On Mon, Aug 05, 2019 at 03:54:19PM -0400, Jason Merrill
The attached patch has be regression tested on x86_64-*-freebsd.
The testcase in the PR explains what the patch does.
% cat z1.f90
subroutine sub (x)
use iso_fortran_env, only: x => character_kinds
end
% gfcx -c a.f90
a.f90:1:17:
1 | subroutine sub (x)
| 1
2 |
After I submitted the patches, Aaron Sawdey tested the branch that has
the patches on it, along with Alan's TLS patches. Alan's patch causes
the functions that determine if the insn is prefixed or not to be run
earlier that before. The compiler was dying because the virtual arg
pointer and frame
On 8/15/19 6:29 PM, Richard Biener wrote:
>>>
>>> Please split it into the parts for the PR and parts making the
>>> asserts not trigger.
>>>
>>
>> Yes, will do.
>>
Okay, here is the rest of the PR 89544 fix,
actually just an optimization, making the larger stack alignment
known to the middle-end,
Hi,
this is the split out part from the "Fix not 8-byte aligned ldrd/strd on ARMv5
(PR 89544)"
which is sanitizing the middle-end interface to the back-end for strict
alignment,
and a couple of bug-fixes that are necessary to survive boot-strap.
It is intended to be applied after the PR 89544 fi
Hi,
as discussed in the PR 91109 audit trail,
my previous patch missed a case where no spilling is necessary,
but the re-materialized instruction has now scratch regs without
a hard register assignment. And thus the LRA pass falls out of
the loop pre-maturely.
Fixed by checking for scratch regs
On Thu, Aug 15, 2019 at 2:35 PM Thomas Koenig wrote:
>
> Hello world,
>
> this patch fixes PR 91443, in which we did not warn about a mismatched
> external procedure. The problem was that the module this was called in
> was resolved before parsing of the procedure ever started.
>
> The approach ta
Hi!
On Thu, Aug 15, 2019 at 01:35:10PM +0930, Alan Modra wrote:
> Supporting TLS for -mpcrel turns out to be relatively simple, in part
> due to deciding that !TARGET_TLS_MARKERS with -mpcrel is silly. No
> assembler that I know of supporting prefix insns lacks TLS marker
> support.
Will this st
On 8/15/19 10:56 AM, Martin Sebor wrote:
> The comment for DECL_SIZE makes it clear it may be non-constant
> but not that it may be null. The comment for TYPE_SIZE mentions
> neither.
>
> The attached update adds a few sentences to make these caveats
> clear. If no one has any suggestions I'll c
On 8/15/19 2:13 AM, Alexandre Oliva wrote:
> The regexp that checks that -lgcov is linked in when --coverage is
> passed to the compiler driver requires the command line to match
> '/collect2'. Some of our targets don't match that, but they match /ld
> or ${target_alias}-ld depending on the testin
On 8/15/19 2:17 AM, Alexandre Oliva wrote:
> Since alloca.h is not ISO C, most of our alloca-using tests seem to
> rely on __builtin_alloca instead of including the header and calling
> alloca. This patch extends this practice to some of the exceptions I
> found in gcc.target, marking them as requ
On 8/15/19 9:46 AM, Alexandre Oliva wrote:
> Testcases that require support for trampolines should be marked as
> such; gcc.target/i386/pr85044.c was missing it. Fixed.
>
> Tested on x86_64-linux-gnu. Ok to install?
>
>
> for gcc/testsuite/ChangeLog
>
> * gcc.target/i386/pr85044.c: Req
This patch adds a port for the Linux kernel eBPF architecture to GCC.
ChangeLog:
* configure.ac: Support for bpf-*-* targets.
* configure: Regenerate.
contrib/ChangeLog:
* config-list.mk (LIST): Disable go in bpf-*-* targets.
gcc/ChangeLog:
* config.gcc: Support for bpf-*-* targets.
The comment for DECL_SIZE makes it clear it may be non-constant
but not that it may be null. The comment for TYPE_SIZE mentions
neither.
The attached update adds a few sentences to make these caveats
clear. If no one has any suggestions I'll commit it as obvious
today or tomorrow.
Thanks
Marti
On August 15, 2019 4:52:24 PM GMT+02:00, Bernd Edlinger
wrote:
>On 8/15/19 2:54 PM, Richard Biener wrote:
>> On Thu, 15 Aug 2019, Bernd Edlinger wrote:
>>
>>
>> Hmm. So your patch overrides user-alignment here. Woudln't it
>> be better to do that more conciously by
>>
>>
On Thu, Aug 15, 2019 at 3:47 PM Alexandre Oliva wrote:
>
> On Aug 15, 2019, Uros Bizjak wrote:
>
> > The immediate of lea is limited to +-2GB
>
> ... and we're talking about a code offset within a tiny translation
> unit, with both reference and referenced address within the same
> section. It w
On 15/08/19 17:04 +0100, Jonathan Wakely wrote:
In C++17 a function can return a prvalue of a type that cannot be moved
or copied. The current implementation of std::is_invocable_r uses
std::is_convertible to test the conversion to R required by INVOKE.
That fails for non-copyable prvalues, becau
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of:
htt
In C++17 a function can return a prvalue of a type that cannot be moved
or copied. The current implementation of std::is_invocable_r uses
std::is_convertible to test the conversion to R required by INVOKE.
That fails for non-copyable prvalues, because std::is_convertible is
defined in terms of std
Testcases that require support for trampolines should be marked as
such; gcc.target/i386/pr85044.c was missing it. Fixed.
Tested on x86_64-linux-gnu. Ok to install?
for gcc/testsuite/ChangeLog
* gcc.target/i386/pr85044.c: Require support for trampolines.
---
gcc/testsuite/gcc.target
Hi all,
I'm trying to add a define_subst use in the arm backend but am getting
many build errors complaining about:
`set_attr_alternative' is unsupported by `define_subst'
Looking at the gensupport.c code it iterates over all define_insns and
errors if any of them have set_attr_alternative.
Hi.
There's forgotten patch for libsanitizer that was not listed
in LOCAL_PATCHES. I've just tested the patch on ppc64
(gcc110 compile farm machine) and I'm going to install the patch.
Martin
>From 82662f97b6bacf21eee1185bc116aa22c0c89b33 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 15
> On Tue, Aug 6, 2019 at 5:43 PM Martin Liska wrote:
> >
> >
> > gcc/ChangeLog:
>
> + /* Virtual table call. */
> + case OBJ_TYPE_REF:
> + {
> + if (!operand_equal_p (OBJ_TYPE_REF_EXPR (arg0),
> + OBJ_TYPE_REF_EXPR (arg1), flags))
> +
On 8/15/19 2:54 PM, Richard Biener wrote:
> On Thu, 15 Aug 2019, Bernd Edlinger wrote:
>
>
> Hmm. So your patch overrides user-alignment here. Woudln't it
> be better to do that more conciously by
>
> if (! DECL_USER_ALIGN (decl)
> || (align < GET_MODE_ALIGNMENT (
> On Fri, Aug 9, 2019 at 3:57 PM Martin Liška wrote:
> >
> > Hi.
> >
> > The patch is about prevention of LTO section name clashing.
> > Now we have a situation where body of 2 functions is streamed
> > into the same ELF section. Then we'll end up with smashed data.
> >
> > Patch can bootstrap on
> On Thu, Aug 1, 2019 at 3:10 PM Martin Liška wrote:
> >
> > Hi.
> >
> > In LTO WPA mode we don't have to append temp file name
> > to the global cdtor function names.
>
> Is that true? You can link with -r -flinker-output=rel and use
> multiple WPA phases whose results you then finally link.
>
On Thu, 15 Aug 2019, Richard Biener wrote:
> On Thu, 15 Aug 2019, Bernd Edlinger wrote:
> > >
> > > We can't subset an SSA_NAME. I have really no idea what this intended
> > > to do...
> > >
> >
> > Nice, so would you do a patch to change that to a
> > gcc_checking_assert (TREE_CODE (tem) != S
If a target does not support libbacktrace, it might still need the include
for $(top_srcdir).
Regenerate the built files using automake-1.15.1
bootstrapped on x86_64-darwin16, x86_64-linux-gnu and
powerpc64-linux-gnu (with a fix for pr90639 applied for this).
Iain
libsanitizer/
2019-08-15 Iain
> On Tue, Aug 6, 2019 at 5:44 PM Martin Liska wrote:
> >
> >
> > gcc/ChangeLog:
>
> So I suppose this isn't to call operand_equal_p on two FIELD_DECLs
> but to make two COMPONENT_REFs "more equal"? If so I then
yes. The patch originates from my original patchset I believe and it is
what ICF doe
On Thu, Aug 15, 2019 at 3:30 PM Richard Sandiford
wrote:
>
> TARGET_SETUP_INCOMING_VARARG_BOUNDS seems to be an unused vestige of the
> MPX support.
>
> Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
OK.
> Richard
>
>
> 2019-08-15 Richard Sandiford
>
> gcc/
> * targ
On Aug 15, 2019, Uros Bizjak wrote:
> The immediate of lea is limited to +-2GB
... and we're talking about a code offset within a tiny translation
unit, with both reference and referenced address within the same
section. It would be very surprising if the offset got up to 2KB, let
alone 2GB ;-)
TARGET_SETUP_INCOMING_VARARG_BOUNDS seems to be an unused vestige of the
MPX support.
Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
Richard
2019-08-15 Richard Sandiford
gcc/
* target.def (setup_incoming_vararg_bounds): Remove.
* doc/tm.texi (TARGET_SETUP_
Hi,
here is updated version.
> > + /* We generally assume that both access paths starts by same sequence
> > +of refs. However if number of array refs is not in sync, try
> > +to recover and pop elts until number match. This helps the case
> > +where one access path st
On Thu, 8 Aug 2019 at 11:22, Prathamesh Kulkarni
wrote:
>
> On Thu, 1 Aug 2019 at 15:34, Prathamesh Kulkarni
> wrote:
> >
> > On Thu, 25 Jul 2019 at 11:56, Prathamesh Kulkarni
> > wrote:
> > >
> > > On Wed, 17 Jul 2019 at 18:15, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Wed, 17 Jul 20
The attached committed patches fix various GNU style violations in the msp430
backend.
The fixed problems include:
- Incorrect indentation
- Whitespace before left square bracket
- 8 spaces used instead of tab
- Whitespace before closing parenthesis
- Lines more than 80 characters long
Successful
On Thu, Aug 15, 2019 at 3:01 PM Alexandre Oliva wrote:
>
> On Aug 15, 2019, Uros Bizjak wrote:
>
> > On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva wrote:
>
> >> If we just use the best-suited way to
> >> take the address of a function behind the compiler's back on each
> >> target variant, we'
On 8/15/19 7:23 AM, Richard Biener wrote:
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of:
ht
On Aug 15, 2019, Uros Bizjak wrote:
> On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva wrote:
>> If we just use the best-suited way to
>> take the address of a function behind the compiler's back on each
>> target variant, we're less likely to hit unexpected failures.
> Perhaps we should use tr
On Thu, 15 Aug 2019, Bernd Edlinger wrote:
> On 8/15/19 10:55 AM, Richard Biener wrote:
> > On Wed, 14 Aug 2019, Bernd Edlinger wrote:
> >
> >> On 8/14/19 2:00 PM, Richard Biener wrote:
> >>
> >> Well, yes, but I was scared away by the complexity of emit_move_insn_1.
> >>
> >> It could be done, b
On Thu, Aug 15, 2019 at 1:39 PM Alexandre Oliva wrote:
>
> gcc.target/i386/asm-4.c uses amd64's natural PC-relative addressing
> mode on a single platform, using the 32-bit absolute addressing mode
> elsewhere. There's no point in giving up amd64's natural addressing
> mode and insisting on the 3
With Concepts, overloads of special member functions can differ in
constraints, and this paper clarifies how that affects class properties: if
a class has a more constrained trivial copy constructor and a less
constrained non-trivial copy constructor, it is still trivially copyable.
Tested x86_64-
On Thu, 15 Aug 2019, Jason Merrill wrote:
> On 8/12/19 6:01 PM, Lewis Hyatt wrote:
> > Hello-
> >
> > The attached patch for libcpp adds support for extended characters (e.g.
> > UTF-8)
> > in identifiers. A preliminary version of the patch was posted on PR c/67224
> > as
> > Comment 26 (https://
On 8/15/19 10:55 AM, Richard Biener wrote:
> On Wed, 14 Aug 2019, Bernd Edlinger wrote:
>
>> On 8/14/19 2:00 PM, Richard Biener wrote:
>>
>> Well, yes, but I was scared away by the complexity of emit_move_insn_1.
>>
>> It could be done, but in the moment I would be happy to have these
>> checks of
Oops, I forgot to update the MAINTAINERS file a couple of months ago,
when the address there stopped working.
Honestly, I haven't really had much involvement with the frv, mn10300
or sh ports for almost 15 years, so I wouldn't mind if someone else
stepped up and took over, but until someone does,
Hi!
This is another approved part from my patch "Fix not 8-byte aligned ldrd/strd
on ARMv5 (PR 89544)"
committed as "obvious".
$ svn diff -r274530:274531 -x -p
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (Revision 274530)
+++ g
gcc.target/i386/asm-4.c uses amd64's natural PC-relative addressing
mode on a single platform, using the 32-bit absolute addressing mode
elsewhere. There's no point in giving up amd64's natural addressing
mode and insisting on the 32-bit one when we're targeting amd64, and
having to make explicit
Hello world,
this patch fixes PR 91443, in which we did not warn about a mismatched
external procedure. The problem was that the module this was called in
was resolved before parsing of the procedure ever started.
The approach taken here is to move the checking of external procedures
to a stage
Hi all,
On 8/6/19 10:51 AM, Richard Earnshaw (lists) wrote:
On 18/07/2019 18:18, James Greenhalgh wrote:
> On Mon, Jun 10, 2019 at 06:21:05PM +0100, Sylvia Taylor wrote:
>> Greetings,
>>
>> This patch adds the intrinsic functions for:
>> - vld1__x4
>> - vst1__x4
>> - vld1q__x4
>> - vst1q__x4
>>
On Thu, Aug 15, 2019 at 12:47 PM Martin Liška wrote:
>
> PING^1
OK
> On 8/8/19 10:43 AM, Martin Liška wrote:
> > On 8/7/19 4:12 PM, Richard Biener wrote:
> >> On Wed, Aug 7, 2019 at 2:04 PM Martin Liška wrote:
> >>>
> >>> On 8/7/19 12:51 PM, Jakub Jelinek wrote:
> On Wed, Aug 07, 2019 at 1
On Thu, Aug 15, 2019 at 12:40 PM Aldy Hernandez wrote:
>
> On 8/14/19 1:37 PM, Jeff Law wrote:
> > On 8/13/19 6:39 PM, Aldy Hernandez wrote:
> >>
> >>
> >> On 8/12/19 7:46 PM, Jeff Law wrote:
> >>> On 8/12/19 12:43 PM, Aldy Hernandez wrote:
> This is a fresh re-post of:
>
> https://
On 8/15/19 12:21 PM, Iain Sandoe wrote:
> 2) As noted on IRC, the version of automake used in the merge is 1.16.1 but
> the GCC prereqs are for 1.15.1. If it’s intended that automake-1.16.1 should
> be used could this requirement be documented somewhere?
Thank you for heads up. Yes, I should ha
This fixes a regression for GCC 9 which was fixed along modifications
on trunk. The patch backports some refactoring and hereby the
relevant change,
- if (*disambiguate_only)
+ /* If we are looking for redundant stores do not create new hashtable
+ entries from aliasing defs with made up
On Thu, Aug 15, 2019 at 1:09 PM Richard Biener wrote:
>
>
> The following fixes non-recognized RTL gegerated since my STV
> changes. I've added a helper instead of enlarging the code
> even more.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> OK?
>
> Thanks,
> Richard.
>
>
The following fixes non-recognized RTL gegerated since my STV
changes. I've added a helper instead of enlarging the code
even more.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
OK?
Thanks,
Richard.
2019-08-15 Richard Biener
PR target/91454
* config/i386/
This exposes 'sizetype' as __SIZETYPE__ to help writing "portable"
GIMPLE testcases.
Will commit soonish, more testcases might need adjustment
for some targets.
Richard.
2019-08-15 Richard Biener
c-family/
* c-common.c (c_stddef_cpp_builtins): When the GIMPLE FE is
The COMPARE RTX has a special conversion procedure that applies only
to DImode double-word operands. Do not convert single-word SImode and
DImode operands for now.
2019-08-15 Uroš Bizjak
* config/i386/i386-features.c (general_scalar_chain::convert_insn)
: Revert 2019-08-14 change.
PING^1
On 8/8/19 10:43 AM, Martin Liška wrote:
> On 8/7/19 4:12 PM, Richard Biener wrote:
>> On Wed, Aug 7, 2019 at 2:04 PM Martin Liška wrote:
>>>
>>> On 8/7/19 12:51 PM, Jakub Jelinek wrote:
On Wed, Aug 07, 2019 at 12:44:28PM +0200, Martin Liška wrote:
> On 8/7/19 11:51 AM, Richard Bie
On 8/14/19 1:53 PM, Jeff Law wrote:
On 8/13/19 6:51 PM, Aldy Hernandez wrote:
Presumably this was better than moving the implementation earlier.
Actually, it was for ease of review. I made some changes to the
function, and I didn't want the reviewer to miss them because I had
moved the fun
On 8/14/19 1:37 PM, Jeff Law wrote:
On 8/13/19 6:39 PM, Aldy Hernandez wrote:
On 8/12/19 7:46 PM, Jeff Law wrote:
On 8/12/19 12:43 PM, Aldy Hernandez wrote:
This is a fresh re-post of:
https://gcc.gnu.org/ml/gcc-patches/2019-07/msg6.html
Andrew gave me some feedback a week ago, and I o
Hi Martin,
> On 14 Aug 2019, at 17:18, Jeff Law wrote:
>
> On 8/14/19 2:50 AM, Martin Liška wrote:
>> On 8/13/19 5:02 PM, Jeff Law wrote:
>>> On 8/13/19 7:07 AM, Martin Liska wrote:
Hi.
For this year, I decided to make a first merge now and the
next (much smaller) at the end
In this PR we were passing an ordinary non-built-in function to
targetm.vectorize.builtin_md_vectorized_function, which is only
supposed to handle BUILT_IN_MD.
Tested on aarch64-linux-gnu and spot-checked on powerpc64el-linux-gnu.
Applied as obvious (r274524).
Richard
2019-08-15 Richard Sandif
This patch adds an exported function for testing whether a mode is
an SVE mode. The ACLE will make more use of it, but there's already
one place that can benefit.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274523.
Richard
2019-08-15 Richard Sandiford
On Tue, Aug 13, 2019 at 9:54 PM H.J. Lu wrote:
> > > with the latest patch (this is with -m32) where -mstv causes
> > > all spills to go away and the cmoves replaced (so clearly
> > > better code after the patch) for pr65105-5.c, no obvious
> > > improvements for pr65105-3.c where cmov does appea
aarch64_simd_vector_alignment was only giving predicates 16-bit
alignment in VLA mode, not VLS mode. I think the problem is latent
because we can't yet create an ABI predicate type, but it seemed worth
fixing in a standalone patch rather than as part of the main ACLE series.
The ACLE patches have
On Wed, 14 Aug 2019, Bernd Edlinger wrote:
> On 8/14/19 2:00 PM, Richard Biener wrote:
> > On Thu, 8 Aug 2019, Bernd Edlinger wrote:
> >
> >> On 8/2/19 9:01 PM, Bernd Edlinger wrote:
> >>> On 8/2/19 3:11 PM, Richard Biener wrote:
> On Tue, 30 Jul 2019, Bernd Edlinger wrote:
>
> >
>
SVE defines an assembly alias:
MOV pa.B, pb/Z, pc.B -> AND pa.B. pb/Z, pc.B, pc.B
Our and3 pattern was instead using the functionally-equivalent:
AND pa.B. pb/Z, pb.B, pc.B
This patch duplicates pc.B instead so that the alias can be seen
in disassembly.
I wondere
This patch makes us always pass an explicit vector pattern to
aarch64_output_sve_cnt_immediate, rather than assuming it's ALL.
The ACLE patches need to be able to pass in other values.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274520.
Richard
2019-08-15
aarch64_add_offset contains code to decompose all SVE VL-based constants
into native operations. The worst-case fallback is to load the number
of SVE elements into a register and use a general multiplication.
This patch improves that fallback by reusing expand_mult if
can_create_pseudo_p, rather t
The scalar addition patterns allowed all the VL constants that
ADDVL and ADDPL allow, but wrote the instructions as INC or DEC
if possible (i.e. adding or subtracting a number of elements * [1, 16]
when the source and target registers the same). That works for the
cases that the autovectoriser nee
The current SVE REV patterns follow the AArch64 scheme, in which
UNSPEC_REV reverses elements within an -bit granule.
E.g. UNSPEC_REV64 on VNx8HI reverses the four 16-bit elements
within each 64-bit granule.
The native SVE scheme is the other way around: UNSPEC_REV64 is seen
as an operation on 64-
This patch makes the floating-point conditional FMA patterns provide the
same /z alternatives as the integer patterns added by a previous patch.
We can handle cases in which individual inputs are allocated to the same
register as the output, so we don't need to force all registers to be
different.
We use EXT both to implement vec_extract for large indices and as a
permute. In both cases we can use MOVPRFX to handle the case in which
the first input and output can't be tied.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274515.
Richard
2019-08-15 Ric
The floating-point subtraction patterns don't need to handle
subtraction of constants, since those go through the addition
patterns instead. There was a missing MOVPRFX alternative for
FSUBR though.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274514.
Richar
FABD and some immediate instructions were missing MOVPRFX alternatives.
This is tested by the ACLE patches but is really an independent improvement.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274513.
Richard
2019-08-15 Richard Sandiford
Kug
This patch makes us use reversed SVE shifts when the first operand
can't be tied to the output but the second can. This is tested
more thoroughly by the ACLE patches but is really an independent
improvement.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274512
This will be tested by the ACLE patches, but it's really an
independent improvement.
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274510.
Richard
2019-08-15 Richard Sandiford
gcc/
* config/aarch64/aarch64-sve.md (aarch64_abd_3): Add
a co
This patch uses predicated MLA, MLS, MAD and MSB to implement
conditional "FMA"s on integers. This also requires providing
the unpredicated optabs (fma and fnma) since otherwise
tree-ssa-math-opts.c won't try to use the conditional forms.
We still want to use shifts and adds in preference to mult
This patch lets us use the immediate forms of FADD, FSUB, FSUBR,
FMUL, FMAXNM and FMINNM for conditional arithmetic. (We already
use them for normal unconditional arithmetic.)
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274508.
Richard
2019-08-15 Richard
Since alloca.h is not ISO C, most of our alloca-using tests seem to
rely on __builtin_alloca instead of including the header and calling
alloca. This patch extends this practice to some of the exceptions I
found in gcc.target, marking them as requiring a functional alloca
while at that.
Tested on
This patch extends the FABD support so that it handles conditional
arithmetic. We're relying on combine for this, since there's no
associated IFN_COND_* (yet?).
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274507.
Richard
2019-08-15 Richard Sandiford
The regexp that checks that -lgcov is linked in when --coverage is
passed to the compiler driver requires the command line to match
'/collect2'. Some of our targets don't match that, but they match /ld
or ${target_alias}-ld depending on the testing scenario, so I'd like
to tweak the test to match
This patch extends the [SU]ABD support so that it handles
conditional arithmetic. We're relying on combine for this,
since there's no associated IFN_COND_* (yet?).
Tested on aarch64-linux-gnu (with and without SVE) and aarch64_be-elf.
Applied as r274506.
Richard
2019-08-15 Richard Sandiford
"Jose E. Marchesi" writes:
> . Dynamic stack allocation (alloca and VLAs) is achieved by using what
> otherwise would be a perfectly normal general register, %r9, as a
> pseudo stack pointer. This has the disadvantage of making the
> register "fixed" and therefore not available for general
97 matches
Mail list logo
