From: Cory Fields
Related to PR82407.
These two unstable sorts caused bootstrap comparison failures when crossing
from glibc to musl.
I'm not 100% sure about the correctness of the fixes, but I can verify that
when applied, bootstrap is successful.
Cory Fields (2):
Fix unstable sort
Fix uns
From: Cory Fields
2018-01-12 Cory Fields
* tree-ssa-loop-im.c (sort_bbs_in_loop_postorder_cmp): stabilize sort
---
gcc/ChangeLog | 3 +++
gcc/tree-ssa-loop-im.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4b4b577..a
From: Cory Fields
2018-01-12 Cory Fields
* tree-ira.c (allocno_hard_regs_compare): stabilize sort
---
gcc/ChangeLog | 3 +++
gcc/ira-color.c | 3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ab96bd6..546e84c 100644
--- a/gcc/C
On 31/08/2023 07:39, Richard Biener wrote:
On Wed, Aug 30, 2023 at 5:02 PM Andre Vieira (lists)
wrote:
On 30/08/2023 14:01, Richard Biener wrote:
On Wed, Aug 30, 2023 at 11:15 AM Andre Vieira (lists) via Gcc-patches
wrote:
This patch adds a machine_mode parameter to the
Hi Honza,
My current patch set for AArch64 VLA omp codegen started failing on
gcc.dg/gomp/pr87898.c after this. I traced it back to
'move_sese_region_to_fn' in tree/cfg.cc not setting count for the bb
created.
I was able to 'fix' it locally by setting the count of the new bb to the
accumula
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd clones. We use this in two ways, the first one is to
make sure we can create valid SVE types
On 04/10/2023 11:41, Richard Biener wrote:
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
This patch adds a new target hook to enable us to adapt the types of return
and parameters of simd
On 28/09/2023 12:55, Siddhesh Poyarekar wrote:
> +Security features implemented in GCC
> +
> +
[...]
> +
> +Similarly, GCC may transform code in a way that the correctness of
> +the expressed algorithm is preserved, but supplementary properties
> +tha
On 09/10/2023 14:12, Victor Do Nascimento wrote:
>
>
> On 10/7/23 12:53, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 03/10/2023 16:18, Victor Do Nascimento wrote:
In implementing the ACLE read/write system register builtins it was
observed that leaving argument type che
On 11/10/2023 14:56, Jeff Law wrote:
>
>
> On 10/11/23 04:39, Florian Weimer wrote:
>> I've started to look at what it is required to convert the testsuite to
>> C99 (without implicit ints, without implicit function declarations, and
>> a few other legacy language features).
> I bet those older t
On 05/09/2023 16:00, Richard Sandiford via Gcc-patches wrote:
> Szabolcs Nagy writes:
>> Update tests for the new branch-protection parser errors.
>>
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/aarch64/branch-protection-attr.c: Update.
>> * gcc.target/aarch64/branch-protection-option.
Hey,
Just a minor update to the patch, I had missed the libgomp testsuite, so
had to make some adjustments there too.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (lane_size): New function.
(aarch64_simd_clone_compute_vecsize_and_simdlen): Determine
simdlen according to NDS rul
So OK to commit this?
This patch makes sure the profile_count information is initialized for
the new
bb created in move_sese_region_to_fn.
gcc/ChangeLog:
* tree-cfg.cc (move_sese_region_to_fn): Initialize profile_count for
new basic block.
Bootstrapped and regression tested o
ings got a
bit confusing with removing and adding patches to the series.
On 30/08/2023 09:49, Andre Vieira (lists) via Gcc-patches wrote:
Hi,
This patch series aims to implement support for SVE simd clones when not
specifying a 'simdlen' clause for AArch64. This patch depends on my
earlie
Just posting a rebase for completion.
On 30/08/2023 13:31, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
SVE simd clones require to be compiled with a SVE target enabled or the
argument types will not be created properly. To achieve this we need to copy
Posting the changed patch for completion, already reviewed.
On 30/08/2023 13:32, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
Teach parloops how to handle a poly nit and bound e ahead of the changes to
enable non-constant simdlen.
Can you use poly_int_tree_p to
helper function.
On 30/08/2023 13:54, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
The vect_get_smallest_scalar_type helper function was using any argument to a
simd clone call when trying to determine the smallest scalar type that would
be vectorized. This included
Rebased, needs review.
On 30/08/2023 10:13, Andre Vieira (lists) via Gcc-patches wrote:
This patch enables the compiler to use inbranch simdclones when
generating masked loops in autovectorization.
gcc/ChangeLog:
* omp-simd-clone.cc (simd_clone_adjust_argument_types): Make function
Refactor simd clone handling code ahead of support for poly simdlen.
gcc/ChangeLog:
* omp-simd-clone.cc (simd_clone_subparts): Remove.
(simd_clone_init_simd_arrays): Replace simd_clone_supbarts with
TYPE_VECTOR_SUBPARTS.
(ipa_simd_modify_function_body): Likewise.
Rebased on top of trunk, minor change to check if loop_vinfo since we
now do some slp vectorization for simd_clones.
I assume the previous OK still holds.
On 30/08/2023 13:54, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:
When analyzing a loop and choosing a
Rebased, no major changes, still needs review.
On 30/08/2023 10:19, Andre Vieira (lists) via Gcc-patches wrote:
This patch finalizes adding support for the generation of SVE simd
clones when no simdlen is provided, following the ABI rules where the
widest data type determines the minimum
ter return
and argument types have been vectorized.
On 04/10/2023 13:40, Andre Vieira (lists) wrote:
On 04/10/2023 11:41, Richard Biener wrote:
On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:
On 30/08/2023 14:04, Richard Biener wrote:
On Wed, 30 Aug 2023, Andre Vieira (lists) wr
On 29/06/18 14:29, Kyrill Tkachov wrote:
> Hi all,
>
> This patch adds support for the Arm Cortex-A76 processor in changes.html
> for GCC 9.
> It enables the AArch64 section of the page and adds the news blob there.
> It also adds an entry to the already-existing arm entry.
>
> Ok to commit to CV
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:
>>
>>> Hi,
>>> this patch adds dumpfile support for dumps that come in multiple
>>> parts. This
>>> is needed for WPA stream-out dump since we stream partit
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
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
extens
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 deletion(-
On 10/07/18 08:19, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
> wrote:
>>
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was needed.
On 10/07/18 00:13, Jeff Law wrote:
> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>
>> The patches I posted earlier this year for mitigating against
>> CVE-2017-5753 (Spectre variant 1) attracted some useful feedback, from
>> which it became obvious that a rethink was needed. This mail, and th
On 10/07/18 11:10, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 08:19, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 6:39 PM Richard Earnshaw
>>> wrote:
>>>>
>>>>
>&g
On 10/07/18 12:21, Richard Biener wrote:
> On Tue, Jul 10, 2018 at 12:53 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 10/07/18 11:10, Richard Biener wrote:
>>> On Tue, Jul 10, 2018 at 10:39 AM Richard Earnshaw (lists)
>>> wrote:
>>>>
>>&g
On 10/07/18 14:48, Bill Schmidt wrote:
>
>> On Jul 10, 2018, at 3:49 AM, Richard Earnshaw (lists)
>> wrote:
>>
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>>
>>>> The patches I posted
On 10/07/18 16:42, Jeff Law wrote:
> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>> On 10/07/18 00:13, Jeff Law wrote:
>>> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>>>>
>>>> To address all of the above, these patches adopt a new ap
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 c
On 12/06/18 11:03, Tom de Vries wrote:
> [ Fixed ENOPATCH ]
>
> On Tue, Jun 12, 2018 at 11:57:13AM +0200, Tom de Vries wrote:
>> [ was: Re: [MAINTAINERS, committed] Remove redundant write-after-approval
>> entries ]
>>
>> On Tue, Jun 12, 2018 at 10:26:31AM +0200, Martin Liška wrote:
>>> Hi.
>>>
>>
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:
>>
As part of the transition from the original support for named FPUs to
general FPU properties I defined an entry in the CPU definitions in
arm-cpus.in to use a named FPU. However, that has now outlived its
usefulness and increasingly we are likely to find that newer cores do
not fit the legacy FPU
On 11/07/18 21:46, Jeff Law wrote:
> On 07/10/2018 10:43 AM, Richard Earnshaw (lists) wrote:
>> On 10/07/18 16:42, Jeff Law wrote:
>>> On 07/10/2018 02:49 AM, Richard Earnshaw (lists) wrote:
>>>> On 10/07/18 00:13, Jeff Law wrote:
>>>>> O
On 11/07/18 17:48, Jackson Woodruff wrote:
> Hi Sudi,
>
> Thanks for the review.
>
>
> On 07/10/2018 10:56 AM, Sudakshina wrote:
>> Hi Jackson
>>
>>
>> - if (!MEM_P (mem_1) || aarch64_mem_pair_operand (mem_1, mode))
>> + if (!MEM_P (mem[1]) || aarch64_mem_pair_operand (mem[1], mode))
>>
>> mem
On 12/07/18 15:22, Ramana Radhakrishnan wrote:
> Hi,
>
>
> I've had this in my patch stack after discovering the gas issue where we
> weren't warning on cases that were unpredictable according to the
> architecture.
>
> I would like to backport this fix to earlier GCC branches too. I did a
> few
On 11/07/18 17:48, Jackson Woodruff wrote:
> Hi Sudi,
>
> On 07/10/2018 02:29 PM, Sudakshina Das wrote:
>> Hi Jackson
>>
>>
>> On Tuesday 10 July 2018 09:37 AM, Jackson Woodruff wrote:
>>> Hi all,
>>>
>>> This patch resolves PR86014. It does so by noticing that the last
>>> load may clobber the a
On 13/07/18 00:26, Gerald Pfeifer wrote:
> On Fri, 29 Jun 2018, Kyrill Tkachov wrote:
>> This patch adds support for the Arm Cortex-A76 processor in changes.html
>> for GCC 9. It enables the AArch64 section of the page and adds the news
>> blob there. It also adds an entry to the already-existin
This patch moves the vendor and CPU id data from driver-arm.c to the
main table of CPU data in arm-cpus.in. It then adds rules to
parsecpu.awk to build data tables that can be used by the driver for
automatic CPU detection when running natively. This is the last major
bit of CPU-specific data tha
On 28/09/17 13:31, Joseph Myers wrote:
> Many GCC tests fail for AArch64 with current binutils because of
> assembler warnings of the form "Warning: ignoring incorrect section
> type for .init_array.00100". The same issue was fixed for ARM in
> r247015 by using SECTION_NOTYPE when creating those s
On 17/07/18 12:09, Kyrill Tkachov wrote:
>
> On 02/02/18 15:14, Kyrill Tkachov wrote:
>>
>> On 01/02/18 17:26, Joseph Myers wrote:
>>> On Thu, 1 Feb 2018, Kyrill Tkachov wrote:
>>>
Hi Joseph, aarch64 maintainers,
On 28/09/17 13:31, Joseph Myers wrote:
> Many GCC tests fail for
On 17/07/18 02:33, Richard Henderson wrote:
> On 07/16/2018 10:10 AM, Sam Tebbs wrote:
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -1439,6 +1439,14 @@ aarch64_hard_regno_caller_save_mode (unsigned regno,
>> unsigned,
>> return SImode;
>> }
>>
>> +/* Implement IS_LEFT_CONSECUTIVE. Check if
On 19/07/18 08:30, Martin Liška wrote:
> This is correct version of the patch. Anyway, I'm thinking about the ForceHelp
> attribute. I may do it in a bit different version. Let me come up with one
> another
> version of the patch.
>
> Martin
>
I don't understand how this is supposed to work. -
On 19/07/18 10:56, Martin Liška wrote:
> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
>> On 19/07/18 08:30, Martin Liška wrote:
>>> This is correct version of the patch. Anyway, I'm thinking about the
>>> ForceHelp
>>> attribute. I may do it i
On 19/07/18 11:22, Martin Liška wrote:
> On 07/19/2018 12:01 PM, Richard Earnshaw (lists) wrote:
>> On 19/07/18 10:56, Martin Liška wrote:
>>> On 07/19/2018 11:28 AM, Richard Earnshaw (lists) wrote:
>>>> On 19/07/18 08:30, Martin Liška wrote:
>>>>> This
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 these
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 code an
On 20/07/18 09:04, Martin Liška wrote:
> Hi.
>
> I'm sending patch candidate with suggested target common hook. It allows a
> target
> to list all possible values for an option. Using the API, I implemented
> -march and
> -mtune option listing on i386.
>
> Richard you asked about the values. Ye
On 20/07/18 11:14, Martin Liška wrote:
> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
>> On 20/07/18 09:04, Martin Liška wrote:
>>> Hi.
>>>
>>> I'm sending patch candidate with suggested target common hook. It allows a
>>> target
>&g
On 20/07/18 11:54, Martin Liška wrote:
> On 07/20/2018 12:25 PM, Richard Earnshaw (lists) wrote:
>> On 20/07/18 11:14, Martin Liška wrote:
>>> On 07/20/2018 11:48 AM, Richard Earnshaw (lists) wrote:
>>>> On 20/07/18 09:04, Martin Liška wrote:
>>>>> Hi.
So why is this only changing the double-precision implementation?
Surely, a problem like this will normally be common to both SP and DP
floating-point computations.
R.
On 23/07/18 08:46, Umesh Kalappa wrote:
> Thank you Wilco for the inputs and we agree that the fix break down
> for the case.
>
On 20/07/18 12:06, Martin Liška wrote:
> On 07/20/2018 12:58 PM, Richard Earnshaw (lists) wrote:
>> Modifiers are context dependent. The architecture implies which
>> modifiers can be applied (and what they mean in detail, so, for example,
>> +fp means enable the default f
Ping.
This patch needs reviewing an appropriate maintainer.
I'm aware that the documentation needs extending a bit to provide some
example use cases as discussed in the follow-up to the generic
discussion, but the rest of the patch still stands.
R.
On 09/07/18 17:38, Richard Earnshaw wrote:
>
[sorry, missed this mail somehow]
On 11/07/18 22:01, Jeff Law wrote:
> On 07/09/2018 10:38 AM, Richard Earnshaw wrote:
>> This patch is the main part of the speculation tracking code. It adds
>> a new target-specific pass that is run just before the final branch
>> reorg pass (so that it can clea
On 24/07/18 17:30, Richard Biener wrote:
> On July 24, 2018 5:50:33 PM GMT+02:00, Ramana Radhakrishnan
> wrote:
>> On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener
>> wrote:
>>>
>>> Status
>>> ==
>>>
>>> The GCC 8 branch is frozen for preparation of the GCC 8.2 release.
>>> All changes to th
On 24/07/18 18:26, Richard Biener wrote:
> On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw
> wrote:
>>
>>
>> This patch defines a new intrinsic function
>> __builtin_speculation_safe_value. A generic default implementation is
>> defined which will attempt to use the backend pattern
>> "speculatio
On 24/07/18 22:55, Steve Ellcey wrote:
> On Tue, 2018-07-24 at 22:04 +0100, James Greenhalgh wrote:
>>
>>
>> I'd say this patch isn't desirable for trunk. I'd be interested in use cases
>> that need a static decision on presence of LSE that are not better expressed
>> using higher level language
On 25/07/18 11:36, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
> wrote:
>>
>> On 24/07/18 18:26, Richard Biener wrote:
>>> On Mon, Jul 9, 2018 at 6:40 PM Richard Earnshaw
>>> wrote:
>>>>
>&
On 24/07/18 18:26, Richard Biener wrote:
> So, please make resolve_overloaded_builtin return a no-op on such targets
> which means you can remove the above warning. Maybe such targets
> shouldn't advertise / initialize the builtins at all?
So I tried to make resolve_overloaded_builtin collapse th
On 25/07/18 14:47, Richard Biener wrote:
> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 25/07/18 11:36, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 11:49 AM Richard Earnshaw (lists)
>>> wrote:
>>>>
>>&g
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 informatio
On 26/07/18 13:41, Richard Biener wrote:
> On Thu, Jul 26, 2018 at 12:03 PM Richard Earnshaw (lists)
> wrote:
>>
>> On 25/07/18 14:47, Richard Biener wrote:
>>> On Wed, Jul 25, 2018 at 2:41 PM Richard Earnshaw (lists)
>>> wrote:
>>>>
>>&g
On 27/07/18 01:46, Paul Koning wrote:
>
>
>> On Jul 26, 2018, at 7:34 PM, Joseph Myers wrote:
>>
>> On Wed, 25 Jul 2018, Richard Earnshaw (lists) wrote:
>>
>>>>> Port maintainers DO need to decide what to do about speculation, even if
>&g
On 27/07/18 13:11, Nathan Sidwell wrote:
> On 07/27/2018 05:37 AM, Richard Earnshaw wrote:
>
> +/* Work out the size of the first argument of a call to
> + __builtin_speculation_safe_value. Only pointers and integral types
> + are permitted. Return -1 if the argument type is not supported or
On 27/07/18 13:11, Nathan Sidwell wrote:
> + if (!COMPLETE_TYPE_P (type))
> +goto incompatible;
>
> Are incomplete integral types a thing? (forward enum extension?)
>
I don't think so, at least not at the level of having an instance of
such a type (as opposed to a pointer to one). Enums,
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 31/07/18 14:57, Segher Boessenkool wrote:
> Hi Christophe,
>
> On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote:
>> Since this was committed, I've noticed regressions
>> on aarch64:
>> FAIL: gcc.dg/zero_bits_compound-1.c scan-assembler-not \\(and:
>
> This went from
> an
On 31/07/18 21:51, Ian Lance Taylor via gcc-patches wrote:
> On Tue, Jul 31, 2018 at 12:25 PM, H.J. Lu wrote:
>> On Mon, Jul 30, 2018 at 6:16 AM, Richard Biener wrote:
>>> On Fri, 27 Jul 2018, Richard Earnshaw wrote:
>>>
This patch defines a new intrinsic function
__builtin_specula
On 01/08/18 09:54, Jakub Jelinek wrote:
> On Wed, Aug 01, 2018 at 09:48:50AM +0100, Richard Earnshaw (lists) wrote:
>> Sorry about that, I did run a full bootstrap on x86, but I had the x86
>> mitigation patch applied, so it didn't trip this.
>
> Also, I see
> FAIL:
Hi,
This patch stops lowering of bitfields by ifcvt when they have non-constant
offsets as we are not likely to be able to do anything useful with those
during
vectorization. That also fixes the issue reported in PR 111882, which was
being caused by an offset with a side-effect being lowered,
On 20/10/2023 14:41, Richard Biener wrote:
On Fri, 20 Oct 2023, Andre Vieira (lists) wrote:
Hi,
This patch stops lowering of bitfields by ifcvt when they have non-constant
offsets as we are not likely to be able to do anything useful with those
during
vectorization. That also fixes the
appy
for you to change this once approved by a maintainer.
Kind regards,
Andre
On 11/10/2023 12:34, Stamatis Markianos-Wright wrote:
Hi all,
On 28/09/2023 13:51, Andre Vieira (lists) wrote:
Hi,
On 14/09/2023 13:10, Kyrylo Tkachov via Gcc-patches wrote:
Hi Stam,
The arm parts look sensib
the code that constructed the array for
the return value.
Kind regards,
Andre
On 18/10/2023 15:41, Andre Vieira (lists) wrote:
This patch moves the call to TARGET_SIMD_CLONE_ADJUST until after the
arguments and return types have been transformed into vector types. It
also constructs
Hi,
In a previous patch I did most of the work for this, but forgot to
change the check for number of arguments matching between call and
simdclone. This check should accept calls without a mask to be matched
against simdclones with mask arguments. I also added tests to verify
this feature
On 03/11/2023 07:31, Richard Biener wrote:
OK.
I do wonder about the gfortran testsuite adjustments though.
!GCC$ builtin (sin) attributes simd (inbranch)
! this should not be using simd clone
y4 = sin(x8)
previously we wouldn't vectorize this as no notinbranch simd function
is ava
Hi,
The current codegen code to support VF's that are multiples of a
simdclone simdlen rely on BIT_FIELD_REF to create multiple input
vectors. This does not work for non-constant simdclones, so we should
disable using such clones when
the VF is a multiple of the non-constant simdlen until we
On 14/09/2020 15:19, Wilco Dijkstra wrote:
> The --with-cpu/--with-arch configure option processing not only checks valid
> arguments
> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
> isn't used
> however since a --with-cpu is translated into a -mcpu option which is
>
On 14/09/2020 13:01, Wilco Dijkstra wrote:
> Enable the fast shift feature in Neoverse N1 tuning - this means additions
> with
> a shift left by 1-4 are as fast as addition. This improves multiply by
> constant
> expansions, eg. x * 25 is now emitted using shifts rather than a multiply:
>
> add
On 14/09/2020 20:04, Wilco Dijkstra wrote:
> Hi Richard,
>
>> On 14/09/2020 15:19, Wilco Dijkstra wrote:
>>> The --with-cpu/--with-arch configure option processing not only checks
>>> valid arguments
>>> but also sets TARGET_CPU_DEFAULT with a CPU and extension bitmask. This
>>> isn't used
>>>
On 23/10/2019 09:28, Christophe Lyon wrote:
On 21/10/2019 14:24, Richard Earnshaw (lists) wrote:
On 21/10/2019 12:51, Christophe Lyon wrote:
On 18/10/2019 21:48, Richard Earnshaw wrote:
Each patch should produce a working compiler (it did when it was
originally written), though since the
On 24/10/2019 11:16, Christophe Lyon wrote:
On 23/10/2019 15:21, Richard Earnshaw (lists) wrote:
On 23/10/2019 09:28, Christophe Lyon wrote:
On 21/10/2019 14:24, Richard Earnshaw (lists) wrote:
On 21/10/2019 12:51, Christophe Lyon wrote:
On 18/10/2019 21:48, Richard Earnshaw wrote:
Each
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 com
On 24/10/2019 17:10, Richard Earnshaw (lists) wrote:
On 24/10/2019 11:16, Christophe Lyon wrote:
On 23/10/2019 15:21, Richard Earnshaw (lists) wrote:
On 23/10/2019 09:28, Christophe Lyon wrote:
On 21/10/2019 14:24, Richard Earnshaw (lists) wrote:
On 21/10/2019 12:51, Christophe Lyon wrote
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 nit
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,
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 when
(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
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 (list
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
- gcc.target/i
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 obvi
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 deb
On ARM, the SBC instruction is defined as
Ra - Rb - ~C
where C is the carry flag. But -Rb = ~Rb + 1, so this is equivalent to
Ra + ~Rb + 1 - ~C
which then simplifies to
Ra + ~Rb + C
which is essentially an add-with-carry with one operand inverted. We
can define RTL patterns to match
Thumb2 code now uses the Arm implementation of legitimize_address. That
code has a case to handle addresses that are absolute CONST_INT values,
which is a common use case in deeply embedded targets (eg: void *p =
(void*)0x12345678). Since thumb has very limited negative offsets from
a constan
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 vectorizin
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,
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 epilo
1 - 100 of 1874 matches
Mail list logo
