On 27/07/18 16:39, David Malcolm wrote:
> On Thu, 2018-07-26 at 13:22 +0100, Andre Vieira (lists) wrote:
>
> [...snip...]
>
>>>> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86636.c
>>>> b/gcc/testsuite/gcc.c-torture/compile/pr86636.c
>>>>
On 24/07/18 15:12, Richard Biener wrote:
> On Tue, Jul 24, 2018 at 1:44 AM David Malcolm wrote:
>>
>> There are various ways that it's possible for a gimple statement to
>> have an UNKNOWN_LOCATION, and for that UNKNOWN_LOCATION to be wrapped
>> in an ad-hoc location to capture inlining
On 17/07/18 15:52, James Greenhalgh wrote:
> On Mon, Jun 25, 2018 at 03:48:13AM -0500, Andre Simoes Dias Vieira wrote:
>> On 18/06/18 09:08, Andre Simoes Dias Vieira wrote:
>>> Hi Richard,
>>>
>>> Sorry for the delay I have been on holidays. I had a look and I think you
>>> are right. With
On 17/07/18 16:23, James Greenhalgh wrote:
> On Mon, Jul 09, 2018 at 08:20:53AM -0500, Andre Vieira (lists) wrote:
>> Hi,
>>
>> This patch adds support for the Statistical Profiling Extension (SPE) on
>> AArch64. Even though the compiler will not generate co
On 09/07/18 09:11, Martin Liška wrote:
> Hi.
>
> I'm putting back what I accidentally removed.
>
> Martin
>
> gcc/ChangeLog:
>
> 2018-07-09 Martin Liska
>
> * common.opt: Add back wrongly removed attribute.
> ---
> gcc/common.opt | 2 +-
> 1 file changed, 1 insertion(+), 1
On 09/07/18 22:44, Martin Sebor wrote:
> On 07/09/2018 06:40 AM, Richard Biener wrote:
>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>>>
>>> On 07/06/2018 09:52 AM, Richard Biener wrote:
On Fri, Jul 6, 2018 at 1:54 AM Martin Sebor wrote:
>
> GCC folds accesses to members of
On 11/07/18 11:00, Andre Vieira (lists) wrote:
> On 09/07/18 22:44, Martin Sebor wrote:
>> On 07/09/2018 06:40 AM, Richard Biener wrote:
>>> On Sun, Jul 8, 2018 at 4:56 AM Martin Sebor wrote:
>>>>
>>>> On 07/06/2018 09:52 AM, Richard Biener wrote:
>>
Hi,
This patch adds support for the Statistical Profiling Extension (SPE) on
AArch64. Even though the compiler will not generate code any differently
given this extension, it will need to pass it on to the assembler in
order to let it correctly assemble inline asm containing accesses to the
On 03/07/18 15:15, David Malcolm wrote:
> On Tue, 2018-07-03 at 11:00 +0100, Andre Vieira (lists) wrote:
>> On 29/06/18 11:13, David Malcolm wrote:
>>> On Fri, 2018-06-29 at 10:15 +0200, Richard Biener wrote:
>>>> On Fri, 22 Jun 2018, Jan Hubicka wrote:
>&g
On 17/05/18 09:29, Kyrill Tkachov wrote:
>
> On 16/05/18 10:22, Jérôme Lambourg wrote:
>> Hello Kyrill,
>>
>>> Thanks for the patch! To validate it your changes you can also look
>>> at the disassembly
>>> of the cmse.c binary in the build tree. If the binary changes with
>>> your patch then that
On 05/06/18 11:18, Kyrill Tkachov wrote:
>
> On 05/06/18 11:03, Andre Vieira (lists) wrote:
>> On 05/06/18 10:42, Kyrill Tkachov wrote:
>>> Hi Andre,
>>>
>>> On 05/06/18 10:40, Andre Vieira (lists) wrote:
>>>> Hi all,
>>>>
>>&g
Hi,
This patch enables targets to describe DR_TARGET_ALIGNMENT as a
compile-time variable. It does so by turning the variable into a
'poly_uint64'. This should not affect the current code-generation for
any target.
We hope to use this in the near future for SVE using the
current_vector_size
On 05/11/18 12:41, Richard Biener wrote:
> On Mon, Nov 5, 2018 at 1:07 PM Andre Vieira (lists)
> wrote:
>>
>>
>> Hi,
>>
Hi,
Thank you for the quick response! See inline responses below.
>> This patch enables targets to describe DR_TARGET_ALIGNMENT as a
&
Hi,
I committed a tweaked backport of
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02276.html to the
gcc-8-branch in r267124. There was a small subtle difference, since in
GCC-8 we didn't enable fpu by default for cores, so rather than changing
the default to use the right fpu, I changed
On 27/11/18 14:18, Richard Earnshaw (lists) wrote:
> On 27/11/2018 14:10, Andre Vieira (lists) wrote:
>>
>> Both Cortex-R7 and Cortex-R8 support FP16 conversion instructions and both
>> have
>> SP only and SP + DP configurations.
>
> You're missing the upd
On 28/11/18 10:57, Richard Earnshaw (lists) wrote:
> On 28/11/2018 10:43, Andre Vieira (lists) wrote:
>> On 27/11/18 14:18, Richard Earnshaw (lists) wrote:
>>> On 27/11/2018 14:10, Andre Vieira (lists) wrote:
>>>>
>>>> Both Cortex-R7 and Cortex-R8 sup
Hi,
This patch fixes the FPU configurations of Cortex-R7 and Cortex-R8,
enabling the use of FP16 conversion instructions for both and adding the
option to disable double precision instruction support using '+nofp.dp'.
Passes the self-check during building for an arm target.
Is this OK for
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed to detect whether a register access of 'x'
overlaps with 'set'. For SUBREGs it should check whether any of the
full multi-register overlaps with 'set'. The former behavior used to
grab
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed to detect whether a register access of 'x'
overlaps with 'set'. For SUBREGs it should check whether
Christophe Lyon
* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.
On 12/03/2019 14:54, Andre Vieira (lists) wrote:
Hi,
Thanks Christophe! I have committed a backport of r269499 including the
testism fix r269596 to gcc-8 branch in r269613.
gcc/ChangeLog
Hi,
Any objections to me backporting this to GCC 8 and 7?
Cheers,
Andre
On 08/03/2019 17:30, Andre Vieira (lists) wrote:
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none
Hi,
vcvtb.f16.f64 and vcvtb.f64.f16 were being made available even for FPUs
that do not support double precision. This patch fixes that.
Regression tested for arm-none-eabi.
Committed in r269499.
Cheers,
Andre
gcc/ChangeLog:
2019-03-08 Andre Vieira
* config/arm/arm.h
* gcc.target/arm/f16_f64_conv_no_dp.c: Add arm_fp16_ok effective
target.
On 11/03/2019 20:50, Ramana Radhakrishnan wrote:
Nope, just do it after testing it and adjust with Christophes follow up
R
On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists),
mailto:andre.simoesdiasvie...@arm.com>>
PING.
Since Jeff is away can another maintainer have a look at this please?
Cheers,
Andre
On 01/02/2019 14:31, Andre Vieira (lists) wrote:
On 11/01/2019 22:54, Jeff Law wrote:
On 1/8/19 8:21 AM, Andre Vieira (lists) wrote:
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre
Hi Vlad,
On 13/02/2019 16:46, Vladimir Makarov wrote:
On 2019-02-13 5:54 a.m., Andre Vieira (lists) wrote:
PING.
Since Jeff is away can another maintainer have a look at this please?
I see the following patch
Yeah I uploaded the wrong patch... sorry. See attached, including a
testcase
Hi,
This patch adds the documentation to the FPU configuration fixes for
Cortex-R7 and Cortex-R8 to changes.html for GCC9.
See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02183.html
I have validated the html using the W3C validator.
Is it OK?
Cheers,
Andre
? .changes.html.swp
? patch
cvs
On 11/01/2019 22:54, Jeff Law wrote:
On 1/8/19 8:21 AM, Andre Vieira (lists) wrote:
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed to detect
Hi Richard(s),
I am trying to tackle PR88915 and get GCC to further vectorize the
"fallback" loop when doing loop versioning as it does when loop
versioning is not required.
I have a prototype patch that needs further testing, but at first glance
it seems to be achieving the desired
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I think for code-size reason it would make sense to do it like
if (iterations_check_for_lowest_VF ())
{
if (alias_check_for_highest_VF
Hi,
In this patch series I address PR 88915 in the first patch, by enabling
vectorization of epilogues when doing loop versioning and turn on
--param vect-epilogues-nomask=1 on by default in the second patch.
I benchmarked intrate SPEC2017 for both aarch64 and x86_64 (AVX512).
This patch
Hi,
This patch is an improvement on my last RFC. As you pointed out, we can
do the vectorization analysis of the epilogues before doing the
transformation, using the same approach as used by openmp simd. I have
not yet incorporated the cost tweaks for vectorizing the epilogue, I
would like
Hi,
In this patch I turn epilogue vectorization on by default. I had to
make changes to the tests since the vectorizer dumps now show the
analysis for both the first and second vectorization. This required
checks like 'scan-tree-dump-times' to be raised to meet the new numbers.
For some
Hi Richard,
I have come up with a way to teach the vectorizer to handle
sign-changing reductions, restricted to SUM operations as I'm not sure
other reductions are equivalent with different signs.
The main nature of this approach is to let it recognize reductions of
the form:
Hi Richard,
As I mentioned in the IRC channel, this is my current work in progress
patch. It currently ICE's when vectorizing
gcc/testsuite/gcc.c-torture/execute/nestfunc-2.c with '-O3' and '--param
vect-epilogues-nomask=1'.
It ICE's because the epilogue loop (after if conversion) and main
On 30/07/2019 13:16, Andre Vieira (lists) wrote:
Hi Richard,
I believe this is in line with what you were explaining to me earlier.
The one thing I haven't quite done here is the jump around for if there
is no prolog peeling. Though I think skip_vectors introduces the jumping
we need
ram vect_epilogues_nomask=1' already causes wrong codegen
in SPEC2017 for the gcc and perlbench benchmarks.
Cheers,
Andre
On 19/07/2019 13:38, Andre Vieira (lists) wrote:
On 19/07/2019 12:35, Richard Biener wrote:
On Fri, 19 Jul 2019, Andre Vieira (lists) wrote:
On 15/07/2019 11:54, Ri
Hi Richard,
Thanks for the feedback! See comments inline.
On 01/08/2019 16:26, Richard Biener wrote:
On Tue, 30 Jul 2019, Andre Vieira (lists) wrote:
On 30/07/2019 13:16, Andre Vieira (lists) wrote:
Hi Richard,
I believe this is in line with what you were explaining to me earlier
On 15/07/2019 11:54, Richard Biener wrote:
On Mon, 15 Jul 2019, Andre Vieira (lists) wrote:
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I have code that can split the condition and alias checks in
'vect_loop_versioning
On 19/07/2019 12:35, Richard Biener wrote:
On Fri, 19 Jul 2019, Andre Vieira (lists) wrote:
On 15/07/2019 11:54, Richard Biener wrote:
On Mon, 15 Jul 2019, Andre Vieira (lists) wrote:
On 12/07/2019 11:19, Richard Biener wrote:
On Thu, 11 Jul 2019, Andre Vieira (lists) wrote:
I
Hi,
I was using loop->simdlen to detect whether it was a SIMD loop and I
don't believe that was correct, as can be witnessed by the mass failures
in libgomp. My apologies for not running this, didn't think of it!
I found that these were failing because we do not handle vectorization
of
Hi,
After during my investigation into the first testcase in PR92347 I
noticed that the ICE was arising because the vectorizer was under the
assumption it knew how to vectorize the zp call for both the main and
epilogues. By the time it got to transform the epilogue
Hi,
When investigating PR92317 I noticed that when we create the skip
epilogue condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we
only copy phi-nodes that are not constants in
'slpeel_update_phi_nodes_for_guard2'. This can cause problems later
when we create the scalar epilogue
Sorry for the double post, ignore please.
On 06/11/2019 10:57, Andre Vieira (lists) wrote:
Hi,
When investigating PR92317 I noticed that when we create the skip
epilogue condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we
only copy phi-nodes that are not constants
On 07/11/2019 14:00, Richard Biener wrote:
On Thu, 7 Nov 2019, Andre Vieira (lists) wrote:
Hi,
PR92351 reports a bug in which a wrongly aligned load is generated for an
epilogue of a main loop for which we peeled for alignment. There is no way to
guarantee that epilogue data accesses
Hi,
PR92351 reports a bug in which a wrongly aligned load is generated for
an epilogue of a main loop for which we peeled for alignment. There is
no way to guarantee that epilogue data accesses are aligned when the
main loop is peeling for alignment.
I also had to split vect-peel-2.c as
Hi,
Rebased the patch on top of Richard Sandiford's patches, with his fixes
I can now allow for vectorization of epilogues after we match simdlen.
This will however not turn on epilogue vectorization in cases where we
specify a desired simdlen that is never matched. This would require
more
Hi,
When investigating PR92317 I noticed that when we create the skip
epilogue condition, see ('if (skip_epilog)' in 'vect_do_peeling'), we
only copy phi-nodes that are not constants in
'slpeel_update_phi_nodes_for_guard2'. This can cause problems later
when we create the scalar epilogue
Hi,
I used to have this testcase in my patch when testing but forgot to
include it in the patch I sent upstream. This testcase checks that a
vmovaps isn't generated when vectorizing the loop. When I turn epilogue
vectorization it seems to come back.
@Jakub: This test has -fopenmp but I
On 31/10/2019 14:04, Jakub Jelinek wrote:
On Thu, Oct 31, 2019 at 01:55:26PM +, Andre Vieira (lists) wrote:
I used to have this testcase in my patch when testing but forgot to include
it in the patch I sent upstream. This testcase checks that a vmovaps isn't
generated when vectorizing
Hi,
After my patch I believe the only way orig_loop_vinfo is not null when
calling vect_analyze_loop is when it is called for an epilogue and in
that case we no longer use that variable, since
LOOP_VINFO_ORIG_LOOP_INFO is already set for the epilogue's
loop_vec_info. This patch removes that
Hi,
In this patch I turn epilogue vectorization on by default for all
targets. After some discussions I decided to take the following testing
approach:
1) I have disabled epilogue vectorization for all tests that failed due
to scan-tree-dump failures inside:
- gcc.dg/vect
-
Hi,
As I mentioned in the patch to disable epilogue vectorization for loops
with SIMDUID set, there were still some aarch64 libgomp failures. This
patch fixes those.
The problem was that we were vectorizing a reduction that was only using
one of the parts from a complex number, creating
Hi,
This patch aims at refactoring the vectorizer code to no longer need to
reset DR_OFFSET for epilogue vectorization and instead keep track of
DR_OFFSET changes per dr_vec_info and just update it as needed. I added
a member of type 'tree' called 'offset' to dr_vec_info, which keeps
track
Thanks for pointing it out Rainer. Thanks to that reminder I noticed
there is a different way to achieve this without adding that extra
target check.
This OK?
gcc/testsuite/ChangeLog:
2019-12-12 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: XFAIL for arm big endian.
On 12/12/2019
Consequently whilst looking at the list I noticed these two were missing.
This OK for trunk?
gcc/ChangeLog:
2019-12-13 Andre Vieira
* doc/sourcebuild.texi (arm_little_endian, arm_nothumb):
Documented existing target checks.
On 13/12/2019 13:05, Andre Vieira (lists) wrote
Hi,
We can now vectorize an epilogue for this loop for arm too, so removing
xfail.
Is this OK for trunk? Wasn't entirely sure whether I could commit this
under obvious.
gcc/testsuite/ChangeLog:
2019-12-11 Andre Vieira
* gcc.dg/vect/vect-epilogues.c: Remove xfail for arm.
diff
, Christophe Lyon wrote:
On Wed, 11 Dec 2019 at 12:27, Andre Vieira (lists)
wrote:
Hi,
We can now vectorize an epilogue for this loop for arm too, so removing
xfail.
Is this OK for trunk? Wasn't entirely sure whether I could commit this
under obvious.
This fails on armeb :-(
gcc/testsuite/ChangeLog
Hi
This patch maps multilibs using -march=armv7-r+vfpv3-d16-fp16 and
-march=armv7-r+vfpv3-d16-fp16+idiv to v7+fp. This patch also adds a new
multilib for armv7-r+fp.sp and maps -march=armv7-r+fp.sp+idiv,
-march=armv7-r+vfpv3xd-fp16 and -march=armv7-r+vfpv3xd-fp16+idiv to it.
This solves issues
Hi all,
This patch was pre-approved by richi. This patch makes sure
ensure_base_align only changes alignment if the new alignment is more
restrictive. It already did this if we were dealing with symbols, but
it now does it for all types of declarations.
Committed in revision r277238.
TARGET_MODIFY_CLONE_CGRAPH_NODE.
* doc/tm.texi: Regenerated
On 09/10/2019 16:35, Andre Vieira (lists) wrote:
Adding Jakub to CC'
On 09/10/2019 16:29, Andre Vieira (lists) wrote:
Hi Martin,
I see thank you. For my particular use case I only need to strip
attributes for local symbols. However, if I
Andre Vieira
* gcc.target/arm/cmse/ipa-clone.c: New test.
On 11/10/2019 00:29, Ramana Radhakrishnan wrote:
On Tue, Oct 8, 2019 at 4:21 PM Andre Vieira (lists)
wrote:
Hi,
This patch implements the TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES for the
arm backend to remove
Hi,
We had a chat offline with Kyrill in which he approved committing the
patch now. Unfortunately he isn't able to access his email until
tomorrow to confirm his approval, but given a time sensitive deadline
and the fact that this patch was previously reviewed and accepted on
trunk I am
rations.
* tree-vectorizer.c (try_vectorize_loop_1): Make sure to use already
created loop_vec_info's for epilogues when available. Otherwise
analyse
epilogue separately.
Cheers,
Andre
On 29/10/2019 11:48, Richard Biener wrote:
On Mon, 28 Oct 2019, Andre Vieira (lists) wr
(try_vectorize_loop_1): Make sure to use already
created loop_vec_info's for epilogues when available. Otherwise
analyse
epilogue separately.
Cheers,
Andre
On 28/10/2019 14:16, Richard Biener wrote:
On Fri, 25 Oct 2019, Andre Vieira (lists) wrote:
Hi,
This is the reworked patch after your
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know we can vectorize the epilogue
with. */
+ vector_sizes epilogue_vsizes;
};
please don't enlarge
add new multilib variants and new mappings.
gcc/testsuite/ChangeLog:
2019-10-18 Andre Vieira
* gcc.target/arm/multilib.exp: Add extra tests.
Cheers,
Andre
On 18/10/2019 12:04, Richard Earnshaw (lists) wrote:
On 18/10/2019 11:53, Andre Vieira (lists) wrote:
Hi
This patch maps
Hi,
This piece of code was pre-approved by richi.
Retested by bootstrapping and regression testing on x86_64 (AVX512) and
aarch64.
Committed in revision r277103.
gcc/ChangeLog:
2019-10-17 Andre Vieira
* tree-vect-loop.c (determine_peel_for_niter): New function
contained
Hi,
This piece of code was pre-approved by richi.
Retested by bootstrapping and regression testing on x86_64 (AVX512) and
aarch64.
Committed in revision r277101.
gcc/ChangeLog:
2019-10-17 Andre Vieira
* tree-vect-loop.c (vect_transform_loop): Move code from here...
*
Hi,
This piece of code was pre-approved by richi.
Retested by bootstrapping and regression testing on x86_64 (AVX512) and
aarch64.
Committed in revision r277105.
gcc/ChangeLog:
2019-10-17 Andre Vieira
* tree-vect-loop.c (vect_analyze_loop_2): Use same condition to
decide
Hi,
This is the reworked patch after your comments.
I have moved the epilogue check into the analysis form disguised under
'!epilogue_vinfos.is_empty ()'. This because I realized that I am doing
the "lowest threshold" check there.
The only place where we may reject an epilogue_vinfo is
On 22/10/2019 18:52, Richard Sandiford wrote:
Thanks for doing this. Hope this message doesn't cover too much old
ground or duplicate too much...
"Andre Vieira (lists)" writes:
@@ -2466,15 +2476,65 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree niters,
tree nitersm1
On 22/10/2019 14:56, Richard Biener wrote:
On Tue, 22 Oct 2019, Andre Vieira (lists) wrote:
Hi Richi,
See inline responses to your comments.
On 11/10/2019 13:57, Richard Biener wrote:
On Thu, 10 Oct 2019, Andre Vieira (lists) wrote:
Hi,
+
+ /* Keep track of vector sizes we know
Hi,
In my '[vect]Make vect-epilogues-nomask=1 default' patch, revision
r277659, I apparently put dg-additional-options before dg-options which
seems to be overwritten. This moves the additional options such that
they are used. Sorry if I caused any testism noise!
Committed in r277664 as
Hi Kyrill,
On 10/10/2019 10:53, Kyrill Tkachov wrote:
I'm a bit surprised that TARGET_FMA (which just checks isa_bit_vfpv4)
doesn't imply TARGET_VFP_DOUBLE.
Can one really have a VFPV4 single-precision-only configuration? Richard?
Armv7e-M supports single precision only FPv4, which also
Hi,
After all the discussions and respins I now believe this patch is close
to what we envisioned.
This patch achieves two things when vect-epilogues-nomask=1:
1) It analyzes the original loop for each supported vector size and
saves this analysis per loop, as well as the vector sizes we
Hi,
This patch series is aimed at fixing an issue when cloning a function
with 'cmse_nonsecure_entry' attribute.
Currently if gcc determines to clone a function with this attribute,
both the cloned and original declarations will be compiled as nonsecure
entry functions. The linker eventually
Hi,
This patch adds a new target hook called
TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES. This hook is meant to give each
target the ability to sanitize a cloned's declaration attribute list.
Is this OK for trunk?
Cheers,
Andre
gcc/ChangeLog:
2019-10-08 Andre Vieira
*
Hi,
This patch implements the TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES for the
arm backend to remove the 'cmse_nonsecure_entry' attribute from cmse.
Bootstrapped the series on x86_64 and built arm-none-eabi, running the
cmse testsuite for armv8-m.main and armv8-m.base.
Is this OK for trunk?
Hi Richard,
As I mentioned in the IRC channel, I managed to get "most" of the
regression testsuite working for x86_64 (avx512) and aarch64.
On x86_64 I get a failure that I can't explain, was hoping you might be
able to have a look with me:
"PASS->FAIL: gcc.target/i386/vect-perm-odd-1.c
: Regenerated
On 08/10/2019 17:27, Martin Jambor wrote:
Hi,
On Tue, Oct 08 2019, Andre Vieira (lists) wrote:
Hi,
This patch adds a new target hook called
TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES. This hook is meant to give each
target the ability to sanitize a cloned's declaration attribute list
(default_sanitize_clone_attributes): New.
* doc/tm.texi.in: Document new target hook.
* doc/tm.texi: Regenerated
On 09/10/2019 12:43, Martin Jambor wrote:
Hi,
On Wed, Oct 09 2019, Andre Vieira (lists) wrote:
Hi Martin,
Thanks for the suggestion. I have moved the target hook
Adding Jakub to CC'
On 09/10/2019 16:29, Andre Vieira (lists) wrote:
Hi Martin,
I see thank you. For my particular use case I only need to strip
attributes for local symbols. However, if I were to claim it is only
used for non-externally visible clones than I would also need to make
sure
Hi,
This patch addresses the problem reported in PR92429. When creating an
epilogue for vectorization we have to replace the SSA_NAMEs in the
PATTERN_DEF_SEQs and RELATED_STMTs of the epilogue's loop_vec_infos.
When doing this we were using simplify_replace_tree which always folds
the
What about the previous patch fixing the existing testism by skipping
for big-endian arm using existing target supports?
On 07/01/2020 07:31, Richard Biener wrote:
On Fri, 13 Dec 2019, Andre Vieira (lists) wrote:
Consequently whilst looking at the list I noticed these two were missing
Hello,
Should we try to get this refactoring in stage 3 or park it for next
stage 1?
Cheers,
Andre
On 10/12/2019 13:36, Andre Vieira (lists) wrote:
Hi,
This patch aims at refactoring the vectorizer code to no longer need to
reset DR_OFFSET for epilogue vectorization and instead keep track
Hi all,
This is a prototype I have put together to look at the feasibility and
profitability of vectorizing loops with breaks as suggested in PR 91246.
I am posting this here for comments as I am curious what your opinions
are on my approach. I don't expect much attention to this in stage 4,
Hi,
This patch fixes an ICE we were seeing due to a missing vec_duplicate
pattern.
Regression tested on arm-none-eabi.
Is this OK for trunk?
gcc/ChangeLog:
2020-04-15 Andre Vieira
* config/arm/mve.md (mve_vec_duplicate): New pattern.
(V_sz_elem2): Remove unused mode
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/atomics.md (aarch64_atomic__lse):
scratch register need not be early-clobber. Document the reason
why we cannot use ST.
diff --git a/gcc/config/aarch64/atomics.md
Allow zero as an input; fix constraints; avoid unnecessary split.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c (aarch64_emit_atomic_swap): Remove.
(aarch64_gen_atomic_ldop): Don't call it.
*
The cas insn is a single insn, and if expanded properly need not
be split after reload. Use the proper inputs for the insn.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c (aarch64_expand_compare_and_swap):
Force
Fix constraints; avoid unnecessary split. Drop the use of the atomic_op
iterator in favor of the ATOMIC_LDOP iterator; this is simplier and more
logical for ldclr aka bic.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* config/aarch64/aarch64.c
gcc/ChangeLog:
2020-04-16 Andre Vieira
Backport from mainline.
2018-07-16 Ramana Radhakrishnan
* config/aarch64/atomics.md (aarch64_store_execlusive): Add
early clobber.
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index
Do not zero-extend the input to the cas for subword operations;
instead, use the appropriate zero-extending compare insns.
Correct the predicates and constraints for immediate expected operand.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
*
2020-04-16 Andre Vieira
Backport from mainline.
2019-09-19 Richard Henderson
* config/aarch64/aarch64 (aarch64_split_compare_and_swap):Unify
some code paths;
use aarch64_gen_compare_reg instead of open-coding.
diff --git a/gcc/config/aarch64/aarch64.c
2020-04-16 Andre Vieira
Backport from mainline
2019-09-19 Richard Henderson
* config/aarch64/aarch64.opt (-moutline-atomics): New.
* config/aarch64/aarch64.c (aarch64_atomic_ool_func): New.
(aarch64_ool_cas_names, aarch64_ool_swp_names): New.
2020-04-16 Andre Vieira
Backport from mainline.
2018-10-31 Richard Henderson
* optabs-libfuncs.c (build_libfunc_function_visibility):
New, split out from...
(build_libfunc_function): ... here.
(init_one_libfunc_visibility): New, split out from ...
Hi,
This series backports all the patches and fixes regarding outline
atomics to the gcc-8 branch.
Bootstrapped the series for aarch64-linux-gnu and regression tested.
Is this OK for gcc-8?
Andre Vieira (19):
aarch64: Add early clobber for aarch64_store_exclusive
aarch64: Simplify LSE cas
2020-04-16 Andre Vieira
Backport from mainline
2019-09-25 Richard Henderson
PR target/91833
* config/aarch64/lse-init.c: Include auto-target.h. Disable
initialization if !HAVE_SYS_AUXV_H.
* configure.ac (AC_CHECK_HEADERS): Add sys/auxv.h.
* config.in, configure:
2020-04-16 Andre Vieira
Backport from mainline
2019-08-21 Prathamesh Kulkarni
PR target/90724
* config/aarch64/aarch64.c (aarch64_gen_compare_reg_maybe_ze): Force y
in reg if it fails aarch64_plus_operand predicate.
diff --git a/gcc/config/aarch64/aarch64.c
2020-04-16 Andre Vieira
Backport from mainline
2020-03-31 Jakub Jelinek
PR target/94368
* config/aarch64/constraints.md (Uph): New constraint.
* config/aarch64/atomics.md (cas_short_expected_imm): New mode attr.
(aarch64_compare_and_swap): Use it instead of n in
201 - 300 of 640 matches
Mail list logo
