Hi!
On 4/29/21 7:27 AM, Senthil Kumar Selvaraj wrote:
> I guess it depends on the scope of the PR? If it was about removing cc0,
> then this patch would do. If it was about getting the generated code
> also to be as close to what it was with cc0, then no, it cannot be closed.
I see.
> OTOH, whil
On Thu, Apr 29, 2021 at 6:10 AM Alexandre Oliva wrote:
>
> On Apr 28, 2021, Uros Bizjak wrote:
>
> > On a related note, while looking at gcc/config.gcc, I noticed that
> > there are two identical code blocks under ${target} i[34567]86-*-* and
> > x86-64-*-*. As much as I have eyeballed the code,
On Thu, Apr 29, 2021 at 6:04 AM Alexandre Oliva wrote:
>
> On Apr 28, 2021, Uros Bizjak wrote:
>
> > i386.h is actually the default $tm_file for i386 and x86_64. It is not
> > possible to use x86-64.h without i386.h, so you can simply delete the
> > definition in x86-64.h.
>
> > Regarding _PAD va
DSE performs a backwards walk over stmts removing stores but it
leaves removing resulting dead SSA defs to later passes. This
eats into its own alias walking budget if the removed stores kept
loads live. The following patch adds removal of trivially dead
SSA defs which helps in this situation and
From: LevyHsu
Added implementation for builtin overflow detection, new patterns are listed
below.
---
Addition:
signed addition (SImode in RV32 || DImode in RV64):
add t0, t1, t2
sltit3, t2, 0
slt t
John Paul Adrian Glaubitz writes:
> On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote:
OK for trunk.
>>>
>>> Anything else that keeps us from merging the changes? Would be great to
>>> have the last backend besides CR-16 finally converted to MODE_CC on trunk.
>>
>> Nope. Committed and pushed
On Feb 22, 2021, Richard Biener wrote:
> On Fri, Feb 19, 2021 at 9:08 AM Alexandre Oliva wrote:
>>
>> Here's an improved version of the patch. Regstrapped on
>> x86_64-linux-gnu, with and without a patchlet that moved multi-pieces
>> ahead of setmem, and also tested with riscv32-elf.
>>
>> Is
On Apr 28, 2021, Uros Bizjak wrote:
> On a related note, while looking at gcc/config.gcc, I noticed that
> there are two identical code blocks under ${target} i[34567]86-*-* and
> x86-64-*-*. As much as I have eyeballed the code, I can't find the
> difference, so perhaps these two blocks should h
On Apr 28, 2021, Uros Bizjak wrote:
> i386.h is actually the default $tm_file for i386 and x86_64. It is not
> possible to use x86-64.h without i386.h, so you can simply delete the
> definition in x86-64.h.
> Regarding _PAD variant, please remove it and substitute #ifdef
> ASM_OUTPUT_MAX_SKIP_PA
This patch removes a FIXME I left for myself for GCC 12, along with
adjusting the relevant test.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
DR 1312
* constexpr.c (cxx_eval_constant_expression): Don't check
integer_zerop.
gcc/testsuite/
On 4/28/21 12:53 AM, Richard Biener wrote:
On Wed, Apr 28, 2021 at 1:30 AM Martin Sebor via Gcc-patches
wrote:
The free_lang_data pass is defined entirely in tree.c. Its code
changes only rarely (only 13% commits to tree.c), and unlike
the rest of tree.c, is even more rarely read. The pass i
WG14 N2432, the C2x removal of old-style function definitions, also
changed the function type compatibility rules so that an unprototyped
declaration can be compatible with a non-variadic prototyped
declaration even if some function arguments are changed by the default
argument promotions. I misse
When the compute_objsize_r() function sees a pointer whose target
it can't determine it sets the size of the pointed to object to
the maximum but it doesn't clear the base0 flag to indicate that
the offset need not be zero-based. This is done when the source
is in SSA form but not before. Since
On 4/28/21 2:24 PM, Patrick Palka wrote:
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? [ diff generated w
On Wed, Apr 28, 2021 at 1:18 PM Jim Wilson wrote:
>
> On Tue, Apr 27, 2021 at 12:45 AM Andrew Waterman wrote:
>>
>> > signed addition (SImode with RV64):
>> > add t0, t1, t2
>> > sext.w t3, t0
>> > bne t0, t3, overflow
>>
>> The following version has the same instruction
On Mon, Apr 26, 2021 at 5:45 AM Christoph Muellner
wrote:
> This series provides a cleanup of the current atomics implementation
> of RISC-V:
>
This looks OK to me, other than the issue with address instructions emitted
inside the lr/sc loop. That could be fixed with a follow up patch though.
As reported in bug 82359, the preprocessor does not allow C++ digit
separators in the line number in a #line directive, despite the
standard syntax for that directive using digit-sequence which allows
digit separators.
There is some confusion in that bug about whether C++ is meant to
allow digit s
On 4/28/21 7:59 PM, Senthil Kumar Selvaraj wrote:
>>> OK for trunk.
>>
>> Anything else that keeps us from merging the changes? Would be great to
>> have the last backend besides CR-16 finally converted to MODE_CC on trunk.
>
> Nope. Committed and pushed just now -
> https://gcc.gnu.org/git?p=gcc
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This adds deleter objects for various kinds of protocol pointers to
libcc1. Existing specializations of argument_wrapper are then
replaced with a single specialization that handles all pointer types
via the appropriate deleter. The result here is a bit
This fixes a crash on invalid requires-expression: in this test,
current_template_parms is null so accessing TEMPLATE_PARMS_CONSTRAINTS
is going to fail. So don't crash, but make sure we've complained
already.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
Hi Andrew,
> I thought that was changed not to use the GOT on purpose.
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63874
>
> That is if the symbol is not declared in the TU, then using the GOT is
> correct thing to do.
> Is the testcase gcc.target/aarch64/pr63874.c still working or is not
> tes
On Wed, Apr 28, 2021 at 10:26:44PM +0200, Tobias Burnus wrote:
> On 28.04.21 15:41, Jakub Jelinek wrote:
> > > @@ -261,6 +263,7 @@ gfc_match_omp_variable_list (const char *str,
> > > gfc_omp_namelist **list,
> > > + gfc_gobble_whitespace ();
> > >if ((allow_sections && gfc_peek_ascii_
On 28.04.21 15:41, Jakub Jelinek wrote:
@@ -261,6 +263,7 @@ gfc_match_omp_variable_list (const char *str,
gfc_omp_namelist **list,
+ gfc_gobble_whitespace ();
if ((allow_sections && gfc_peek_ascii_char () == '(')
|| (allow_derived && gfc_peek_ascii_char () == '%')
Is this
On Tue, Apr 27, 2021 at 12:45 AM Andrew Waterman wrote:
> > signed addition (SImode with RV64):
> > add t0, t1, t2
> > sext.w t3, t0
> > bne t0, t3, overflow
>
> The following version has the same instruction count but offers more ILP:
>
> add t0, t1, t2
> addw t3, t1
On Wed, 28 Apr 2021, gengqi-linux via Gcc-patches wrote:
> I have been fixing a bug. It involved the Negative property of options,
> and I have some confusion about it.
Could you please explain the bug at the *user-visible* level? That is,
the particular options passed to the compiler, how tho
On 4/28/2021 1:56 PM, Tom Tromey wrote:
"Jeff" == Jeff Law writes:
Jeff> On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use std::vector in the code that builds
function types. This avoids some explicit memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1pl
> "Jeff" == Jeff Law writes:
Jeff> On 4/27/2021 7:01 PM, Tom Tromey wrote:
>> This changes libcc1 to use std::vector in the code that builds
>> function types. This avoids some explicit memory management.
>>
>> libcc1/ChangeLog
>> 2021-04-27 Tom Tromey
>>
>> * libcp1plugin.cc (plugin_bu
> This patch version is OK.
I just pushed the patch to master in Patrick's behalf.
Hi all!
Situation from PR was already caught earlier locally. So, I've just extracted
appropriate part, it also slightly modifies loop checks related to
non-single-set instructions.
Patch (attached) was successfully bootstrapped/regtested on aarch64-linux on
all active branches (8-12) with mod
Here, at template definition time, ordinary name lookup for 'foo(t)'
finds the deleted function, and so we form a CALL_EXPR thereof. Later
at instantiation time, when initially substituting into this CALL_EXPR
with T=N::A, we end up calling mark_used on this deleted function before
we augment the
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use variadic templates for the "rpc" functions.
This simplifies the code and removes some possibility for mistakes.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (rpc): Use variadic template. Remove overloads.
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use variadic templates for the "call"
functions. The primary benefit is that this simplifies the code.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (call): Use variadic template. Remove overloads.
* marshal
On 4/27/2021 7:00 PM, Tom Tromey wrote:
Now that C++11 can be used in GCC, libcc1 can be changed to use
templates and type traits to handle unmarshalling all kinds of enums.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* marshall.hh (cc1_plugin::unmarshall): Use type traits.
* ma
This makes tsubst_arg_types substitute into a function's parameter types
in left-to-right order instead of right-to-left order, in accordance with
DR 1227.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? [ diff generated with -w to hide noisy whitespace changes ]
On Wed, Apr 28, 2021 at 9:50 AM Wilco Dijkstra via Gcc-patches
wrote:
>
>
> Use a GOT indirection for extern weak symbols instead of a literal - this is
> the same as
> PIC/PIE and mirrors LLVM behaviour. Ensure PIC/PIE use the same offset
> limits for symbols
> that don't use the GOT.
I thoug
John Paul Adrian Glaubitz writes:
> Hi Senthil!
>
>> On Mon, Apr 26, 2021 at 9:20 AM Senthil Kumar Selvaraj via Gcc-patches
>> wrote:
>>>
>>> Hi,
>>>
>>> This is
>>> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563638.html,
>>> rebased against latest gcc master. The only change is mod
On Tue, 2021-04-27 at 18:46 -0500, will schmidt wrote:
> On Mon, 2021-04-26 at 09:35 -0700, Carl Love wrote:
> > Will, Segher:
> >
> > This patch fixes the order of the argument in the vec_rlmi and
> > vec_rlnm builtins. The patch also adds a new test cases to verify
> > the fix.
> >
> > The pat
Hi Richard,
> Just to check: I guess this part is an optimisation, because it
> means that we can share the GOT entry with other TUs. Is that right?
> I think it would be worth having a comment either way, whatever the
> rationale. A couple of other very minor things:
It's just to make the code
Segher, Will:
The agreement for the sign extension builtin was to just make it Endian
aware rather then go with a more complex definition. The prior patch
has been updated with this new functionality.
This patch adds support for the 128-bit extension instruction and
corresponding builtin support
On 28/04/21 17:57 +0100, Jonathan Wakely wrote:
On 07/04/21 18:18 +0100, Jonathan Wakely wrote:
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31, Jonathan
This is an overall refactor of the jump threader, both for the low level
bits in tree-ssa-threadupdate.* and the high level bits in
tree-ssa-threadedge.*.
There should be no functional changes.
Some of the benefits of the refactor are:
a) Eliminates some icky global state (for example the x_vr_v
This refactors the registry and the profitability code from the
backwards threader into two separate classes. It cleans up the code,
and makes it easier for alternate implementations to share code.
Tested on x86-64 Linux.
gcc/ChangeLog:
* tree-ssa-threadbackward.c (class thread_jumps):
Hi Jeff.
This is the jump threader overhaul I sent you last year, along with
further refactors for the backwards threader.
The meat of it is in the first patch, which IIRC, you passed through
the Fedora tester multiple times.
OK for trunk?
Aldy
Hi Jeff.
This is the jump threader overhaul I sent you last year, along with
further refactors for the backwards threader.
The meat of it is in the first patch, which IIRC, you passed through
the Fedora tester multiple times.
OK for trunk?
Aldy
On 28/04/21 18:00 +0100, Jonathan Wakely wrote:
On 28/04/21 17:57 +0100, Jonathan Wakely wrote:
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31, Jonathan
On Wed, Apr 28, 2021 at 06:56:37PM +0200, Tobias Burnus wrote:
> On 28.04.21 16:13, Matthias Klose wrote:
>
> > On 4/27/21 12:22 PM, Tobias Burnus wrote:
> > > Hence, the distro behaviour is only active when configured with
> > > --enable-offload-defaulted.
> > please document that option in gcc/d
Some places in the compiler iterate over all the fixed registers to
check if that register can be used in a particular mode. The idiom is
to iterate over the register and then for that register, if it
supports the current mode to check all that register and any
additional registers needed (HARD_R
On 28/04/21 17:57 +0100, Jonathan Wakely wrote:
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31, Jonathan Wakely via Libstdc++
wrote:
I propose that we
On 4/28/21 6:56 PM, Tobias Burnus wrote:
> On 28.04.21 16:13, Matthias Klose wrote:
>
>> On 4/27/21 12:22 PM, Tobias Burnus wrote:
>>> Hence, the distro behaviour is only active when configured with
>>> --enable-offload-defaulted.
>> please document that option in gcc/doc/install.texi.
>
> Like a
On April 28, 2021 6:37:56 PM GMT+02:00, Jeff Law wrote:
>
>On 4/28/2021 1:59 AM, Richard Biener wrote:
>> This makes sure to fall into the
>delete_unreachable_blocks_update_callgraph
>> handling to remove blocks becoming unreachable when removing EH edges
>> by tracking blocks to need EH cleanup a
On 07/04/21 18:18 +0100, Jonathan Wakely wrote:
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31, Jonathan Wakely via Libstdc++
wrote:
I propose that we
On 07/04/21 17:59 +0100, Jonathan Wakely wrote:
On 07/04/21 13:46 +0100, Jonathan Wakely wrote:
On 07/04/21 15:41 +0300, Ville Voutilainen via Libstdc++ wrote:
On Wed, 7 Apr 2021 at 15:31, Jonathan Wakely via Libstdc++
wrote:
I propose that we deprecate the constructors for C++11/14/17/20 in
On 28.04.21 16:13, Matthias Klose wrote:
On 4/27/21 12:22 PM, Tobias Burnus wrote:
Hence, the distro behaviour is only active when configured with
--enable-offload-defaulted.
please document that option in gcc/doc/install.texi.
Like attached? Or do you have some other wording suggestions?
T
The load_pair_lanes patterns match a vec_concat of two
adjacent 64-bit memory locations as a single 128-bit load.
The Utq constraint made sure that the address was suitable
for a 128-bit vector, but this meant that it allowed some
addresses that aren't valid for the 64-bit element mode.
Two obviou
This patch fixes an oversight in the handling of debug instructions
in rtl-ssa. At the moment (and whether this is a good idea or not
remains to be seen), we maintain a linear RPO sequence of definitions
and non-debug uses. If a register is defined more than once, we use
a degenerate phi to reest
>>
>> OK for backport to GCC 11 (both patches)?
>
> Yes please. Provided releases/gcc-11 is open for backports..
>
Done, thanks.
On 4/28/2021 1:59 AM, Richard Biener wrote:
This makes sure to fall into the delete_unreachable_blocks_update_callgraph
handling to remove blocks becoming unreachable when removing EH edges
by tracking blocks to need EH cleanup and doing that after releasing
dominance info.
This fixes an ICE s
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This is a trivial change to libcc1 to avoid an explicit call to c_str.
Passing by const reference is slightly less wordy.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* compiler.cc (make_regexp): Take const std::string.
(cc1_plugin::compile
On 4/27/2021 7:01 PM, Tom Tromey wrote:
PR c/94669 points out that a couple of spots in libcc1 take a
std::string where a reference would do. This changes these spots to
take a const char *, to reduce the number of copies.
libcc1/ChangeLog
2021-04-27 Tom Tromey
PR c/94669:
On 4/27/2021 7:01 PM, Tom Tromey wrote:
libcc1 has a memory leak when calling fork_exec -- it allocates a new
vector of arguments, but then does not free it anywhere. This patch
changes this code to use std::vector instead.
Note that the previous code tried to avoid bad_alloc. I don't believ
On 4/27/2021 7:01 PM, Tom Tromey wrote:
The C++ plugin defaults to version 0 of the base compiler API.
However, this is a mistake -- version 1 was introduced before the C++
API was even implemented. This switches the default to version 1.
Note that the compiler-side plugin will accept this ver
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes one spot in libcc1 to use static_assert rather than the
old-style array declaration.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc: Use static assert.
OK
jeff
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to ues foreach in a couple of spots.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc (plugin_context::mark): Use foreach.
* libcc1plugin.cc (plugin_context::mark): Use foreach.
OK
jeff
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> Saturating truncation can be expressed using the RTL expressions
> ss_truncate and us_truncate. This patch changes the implementation
> of the vqmovn_* Neon intrinsics to use these RTL expressions rather
> than a pair of unspecs. The redundant unsp
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch updates the attributes of all intrinsics defined in
> arm_acle.h to be consistent with the attributes of the intrinsics defined
> in arm_neon.h. Specifically, this means updating the attributes from:
> __extension__ static
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use std::vector in the code that builds
function types. This avoids some explicit memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc (plugin_build_function_type): Use std::vector.
* lib
On Wed, Apr 28, 2021 at 8:25 AM Richard Biener via Gcc-patches
wrote:
>
> On Mon, Apr 26, 2021 at 9:06 PM Andrew MacLeod via Gcc-patches
> wrote:
> codes where ranger blows up on. EVRP was supposed to be that - I know
> you're somewhat obsessed to turn everything into "ranger" - and for
Richar
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch updates the attributes of all intrinsics defined in
> arm_fp16.h to be consistent with the attributes of the intrinsics defined
> in arm_neon.h. Specifically, this means updating the attributes from:
> __extension__ static
On 4/28/21 3:24 AM, Geng Qi via Gcc-patches wrote:
gcc/ChangeLog:
* doc/options.texi (Negative): Fix the discription so that it matches
the code implementation of prune_options().
---
gcc/doc/options.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/g
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch implements the v[r]addhn2 and v[r]subhn2 Neon
> intrinsic RTL patterns using a vec_concat of a register_operand and an
> ADDSUBHN unspec - instead of just an ADDSUBHN2 unspec. This more
> relaxed pattern allows for more aggre
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the vcvtx Neon intrinsics to use RTL builtins
> rather than inline assembly code, allowing for better scheduling and
> optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu and
> aarch64_be-n
On 4/27/2021 7:01 PM, Tom Tromey wrote:
Change libcc1 to use "= delete" for the copy constructor and
assignment operator, rather than the old approach of private methods
that are nowhere defined.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (argument_wrapper): Use delete for cop
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to inline a trivial method and to use the default
constructor.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* connection.hh (~connection): Use default.
(print): Inline.
* connection.cc (cc1_plugin::connection::~c
On 4/27/2021 7:01 PM, Tom Tromey wrote:
This changes libcc1 to use "override" where appropriate.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (class compiler_triplet_regexp)
(class compiler_driver_filename, class libcp1_connection): Use
"override".
* l
Hi,
Saturating truncation can be expressed using the RTL expressions
ss_truncate and us_truncate. This patch changes the implementation
of the vqmovn_* Neon intrinsics to use these RTL expressions rather
than a pair of unspecs. The redundant unspecs are removed along with
their code iterator.
Reg
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch adds compilation tests to make sure that the output
> of vmla/vmls floating-point Neon intrinsics (fmul, fadd/fsub) is not fused
> into fmla/fmls instructions.
>
> Ok for master?
>
> Thanks,
> Jonathan
>
> ---
>
> gcc/testsui
Hi,
As subject, this patch updates the attributes of all intrinsics defined in
arm_acle.h to be consistent with the attributes of the intrinsics defined
in arm_neon.h. Specifically, this means updating the attributes from:
__extension__ static __inline
__attribute__ ((__always_inline__))
to:
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the floating-point vml[as][q]_lane Neon
> intrinsics to use RTL builtins rather than relying on the GCC vector
> extensions. Using RTL builtins allows control over the emission of
> fmla/fmls instructions (which we d
Wilco Dijkstra via Gcc-patches writes:
> Use a GOT indirection for extern weak symbols instead of a literal - this is
> the same as
> PIC/PIE and mirrors LLVM behaviour.
Just to check: I guess this part is an optimisation, because it
means that we can share the GOT entry with other TUs. Is that
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the floating-point vml[as][q] Neon intrinsics
> to use RTL builtins rather than relying on the GCC vector extensions.
> Using RTL builtins allows control over the emission of fmla/fmls
> instructions (which we don't
As noted in r11-1339-gb6ab9ecd550227684643b41e9e33a4d3466724d8 we define
a non-standard __cpp_lib_constexpr_char_traits feature test macro to
indicate support for P0426R1 and P1032R1. At some point last year the
__cpp_lib_constexpr_string macro was retconned to indicate support for
those papers. Th
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the floating-point vml[as][q]_n Neon
> intrinsics to use RTL builtins rather than inline assembly code, allowing
> for better scheduling and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-
On Wed, Apr 28, 2021 at 3:32 PM Richard Biener wrote:
>
> On Wed, 28 Apr 2021, Uros Bizjak wrote:
>
> > On Wed, Apr 28, 2021 at 1:46 PM Richard Biener wrote:
> > >
> > > On Wed, 28 Apr 2021, Uros Bizjak wrote:
> > >
> > > > On Wed, Apr 28, 2021 at 1:02 PM Richard Biener
> > > > wrote:
> > > > >
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the v[q]tbx Neon intrinsics to use RTL
> builtins rather than inline assembly code, allowing for better scheduling
> and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issues.
>
Hi,
As subject, this patch updates the attributes of all intrinsics defined in
arm_fp16.h to be consistent with the attributes of the intrinsics defined
in arm_neon.h. Specifically, this means updating the attributes from:
__extension__ static __inline
__attribute__ ((__always_inline__))
to:
Hi,
As subject, this patch implements the saturating right-shift and narrow
high Neon intrinsic RTL patterns using a vec_concat of a register_operand
and a VQSHRN_N unspec - instead of just a VQSHRN2_N unspec. This
more relaxed pattern allows for more aggressive combinations and
ultimately better
Hi,
As subject, this patch implements the v[r]addhn2 and v[r]subhn2 Neon
intrinsic RTL patterns using a vec_concat of a register_operand and an
ADDSUBHN unspec - instead of just an ADDSUBHN2 unspec. This more
relaxed pattern allows for more aggressive combinations and ultimately
better code genera
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the v[q]tbl Neon intrinsics to use RTL
> builtins rather than inline assembly code, allowing for better scheduling
> and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issues.
>
Hi,
As subject, this patch rewrites the vcvtx Neon intrinsics to use RTL builtins
rather than inline assembly code, allowing for better scheduling and
optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu and
aarch64_be-none-elf - no issues.
Ok for master?
Thanks,
Jonathan
Hi,
As subject, this patch adds compilation tests to make sure that the output
of vmla/vmls floating-point Neon intrinsics (fmul, fadd/fsub) is not fused
into fmla/fmls instructions.
Ok for master?
Thanks,
Jonathan
---
gcc/testsuite/ChangeLog:
2021-02-16 Jonathan Wright
* gcc.targ
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the vsri[q]_n_p* Neon intrinsics to use RTL
> builtins rather than inline assembly code, allowing for better scheduling
> and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issu
Hi,
As subject, this patch rewrites the floating-point vml[as][q]_laneq Neon
intrinsics to use RTL builtins rather than relying on the GCC vector
extensions. Using RTL builtins allows control over the emission of
fmla/fmls instructions (which we don't want here.)
With this commit, the code genera
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the vsli[q]_n_p* Neon intrinsics to use RTL
> builtins rather than inline assembly code, allowing for better scheduling
> and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issu
Hi,
As subject, this patch rewrites the floating-point vml[as][q]_lane Neon
intrinsics to use RTL builtins rather than relying on the GCC vector
extensions. Using RTL builtins allows control over the emission of
fmla/fmls instructions (which we don't want here.)
With this commit, the code generat
Use a GOT indirection for extern weak symbols instead of a literal - this is
the same as
PIC/PIE and mirrors LLVM behaviour. Ensure PIC/PIE use the same offset limits
for symbols
that don't use the GOT.
Passes bootstrap and regress. OK for commit?
ChangeLog:
2021-04-27 Wilco Dijkstra
Hi,
As subject, this patch rewrites the floating-point vml[as][q] Neon intrinsics
to use RTL builtins rather than relying on the GCC vector extensions.
Using RTL builtins allows control over the emission of fmla/fmls
instructions (which we don't want here.)
With this commit, the code generated by
On Wed, Apr 28, 2021 at 04:30:30PM +0200, Tom de Vries wrote:
> gcc/ChangeLog:
>
> 2021-04-28 Tom de Vries
>
> PR target/100232
> * internal-fn.c (expand_GOMP_SIMT_ENTER_ALLOC)
> (expand_GOMP_SIMT_LAST_LANE, expand_GOMP_SIMT_ORDERED_PRED)
> (expand_GOMP_SIMT_VOTE_ANY, e
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the vpadal_[su]32 Neon intrinsics to use
> RTL builtins rather than inline assembly code, allowing for better
> scheduling and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> iss
Hi,
As subject, this patch rewrites the floating-point vml[as][q]_n Neon
intrinsics to use RTL builtins rather than inline assembly code, allowing
for better scheduling and optimization.
Regression tested and bootstrapped on aarch64-none-linux-gnu - no
issues.
Ok for master?
Thanks,
Jonathan
-
Jonathan Wright via Gcc-patches writes:
> Hi,
>
> As subject, this patch rewrites the [su]paddl[q] Neon intrinsics to use
> RTL builtins rather than inline assembly code, allowing for better
> scheduling and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issu
1 - 100 of 175 matches
Mail list logo
