On Fri, May 17, 2024 at 04:45:05PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > The end goal of the series is to change the definition of
> > aarch64_feature_flags
> > from a uint64_t typedef to a class with 128 bits of storage. This class
> > us
The existing implementation of this function was convoluted, and had
multiple control flow errors that became apparent to me while reading
the code:
1. The initial early return only checked the properties of the first
exclusion in the list, when these properties could be different for
subsequent
Replace the existing typedef with a new class containing two private
uint64_t members.
Most of the preparatory work was carried out in previous commits. The
most notable remaining changes are the addition of the get_isa_mode and
with_isa_mode functions for conversion to or from aarch64_isa_mode
This guarantees that the constant values are actually evaluated at
compile time.
In previous testing, I have observed GCC failing to evaluate and inline
these constant values, which exposed a separate bug in which some of the
required symbols from feature_deps were missing. Richard Sandiford has
This patch is one way to fix some issues I discovered when disallowing
implicit casts to bool from aarch64_feature_flags (in a later patch).
That in turn was necessary to prohibit accidental conversion of an
aarch64_feature_flags value to an integer by first implicitly casting to
a bool (and thus
When aarch64_feature_flags grows to 128 bits, constructing a mask with a
specific indexed value set will become more complicated. Extract this
operation into a separate macro, and preemptively annotate the feature
masks as possibly unused.
gcc/ChangeLog:
* config/aarch64/aarch64-opts.h
The awk scripts that process the .opt files are relatively fragile and
only handle a limited set of data types correctly. The unrecognised
aarch64_feature_flags type is handled as a uint64_t, which happens to be
correct for now. However, that assumption will change when we extend
the mask to 128
Building an aarch64_feature_flags value from data within a gcc_options
or cl_target_option struct will get more complicated in a later commit.
Use a macro to avoid doing this manually in more than one location.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
Currently there are many places where an aarch64_feature_flags variable
is used, but only the bottom three isa mode bits are set and read.
Using a separate data type for these value makes it more clear that
they're not expected or required to have any of their upper feature bits
set. It will also
The name would become misleading in a later commit anyway, and I think
this is marginally more readable.
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_override_options): Remove temporary variable.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
Replace all uses of 0 for aarch64_feature_flags variable initialisation
with the (almost) new macro AARCH64_NO_FEATURES.
This is needed because a later commit will disallow casts to
aarch64_feature_flags from integer types.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
A later commit will disallow such comparisons. We can instead convert
directly to a boolean value, and make sure all such conversions are
explicit.
TODO: FIX SYSREG GATING.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc
(check_required_extensions): Replace comparison
gcc/ChangeLog:
* config/aarch64/aarch64.cc
(aarch64_tune_flags): Remove unused global variable.
(aarch64_override_options_internal): Remove dead assignment.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
AARCH64_NUM_ISA_MODES will be used within aarch64-opts.h in a later
commit.
gcc/ChangeLog:
* config/aarch64/aarch64.h (DEF_AARCH64_ISA_MODE): Move to...
* config/aarch64/aarch64-opts.h (DEF_AARCH64_ISA_MODE): ...here.
diff --git a/gcc/config/aarch64/aarch64-opts.h
The end goal of the series is to change the definition of aarch64_feature_flags
from a uint64_t typedef to a class with 128 bits of storage. This class uses
operator overloading to mimic the existing integer interface as much as
possible, but with added restrictions to facilate type checking and
Is this patch ok? I was hoping to get it merged before 14.1 releases, if it's
not yet too late for that.
On Tue, Apr 30, 2024 at 05:10:45PM +0100, Andrew Carlotti wrote:
> Add target_version attribute to Common Function Attributes and update
> target and target_clones documentation. Move
Add target_version attribute to Common Function Attributes and update
target and target_clones documentation. Move shared detail and examples
to the Function Multiversioning page. Add target-specific details to
target-specific pages.
---
Changes since v1:
- Various typo fixes.
- Reordered
tion is subjective
> and I realise that not everyone will agree with them.
>
> I've also added Sandra to cc: in case she has time to help with this.
> [original patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649071.html]
>
> Andrew Carlotti writes:
> > Ad
On Fri, Apr 12, 2024 at 06:00:24PM +0100, Andrew Carlotti wrote:
> On Fri, Apr 12, 2024 at 04:49:03PM +0100, Richard Sandiford wrote:
> > Andrew Carlotti writes:
> > > We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
> > > one will require ex
On Fri, Apr 12, 2024 at 04:49:03PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
> > one will require extending the feature bitmask). Instead, make the
> > FEAT_LRCPC patterns availabl
We don't yet have a separate feature flag for FEAT_LRCPC2 (and adding
one will require extending the feature bitmask). Instead, make the
FEAT_LRCPC patterns available when either armv8.4-a or +rcpc3 is
specified. On the other hand, we already have a +rcpc flag, so this
dependency can be
FEAT_CSSC is mandatory in the architecture from Armv8.9.
gcc/ChangeLog:
* config/aarch64/aarch64-arches.def: Add CSSC to V8_9A
dependencies.
---
Bootstrapped and regression tested on aarch64. Ok for master?
diff --git a/gcc/config/aarch64/aarch64-arches.def
Resending to CC some relevant reviewers.
I'll remove "memtag", "ssbs" and "ls64" from the AArch64 feature list before
committing, following changes to my recent AArch64 patch series.
On Tue, Apr 09, 2024 at 02:35:48PM +0100, Andrew Carlotti wrote:
> Add t
Some architecture features have been combined under a single command
line flag, but have been assigned multiple FMV feature names with the
command line flag name enabling only a subset of these features in
the FMV specification. I've proposed reallocating names in the FMV
specification to match
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def:
Fix "rmd"->"rdm", and add FMV to "rdma".
* config/aarch64/aarch64.cc (FEAT_RDMA): Define as FEAT_RDM.
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support). We therefore remove unsupported features
from GCC's list
There was an assumption in some places that the aarch64_fmv_feature_data
array contained FEAT_MAX elements. While this assumption held up till
now, it is safer and more flexible to use the array size directly.
Also fix the lower bound in compare_feature_masks to use ">=0" instead
of ">0", and
Some higher priority FMV features were dependent subsets of lower
priority features. Fix this, using the new priorities specified in
https://github.com/ARM-software/acle/pull/279.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def: Reorder FMV entries.
This includes the following changes from v1:
1/5: Add missing testcase update. (I misread my test diffs, but Linaro
precommit picked this up as well.)
2/5: Address review comments and add a testcase.
5/5: Remove "memtag", "ssbs" and "ls64" instead of renaming them.
Bootstrapped and regression
On Wed, Apr 10, 2024 at 07:51:44PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > On Wed, Apr 10, 2024 at 05:42:05PM +0100, Richard Sandiford wrote:
> >> Andrew Carlotti writes:
> >> > On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford
On Wed, Apr 10, 2024 at 05:42:05PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
> >> Andrew Carlotti writes:
> >> > The first three patches are trivial changes to the feature list to
On Tue, Apr 09, 2024 at 04:33:10PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > There was an assumption in some places that the aarch64_fmv_feature_data
> > array contained FEAT_MAX elements. While this assumption held up till
> > now, it is safer and
On Tue, Apr 09, 2024 at 04:43:16PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > The first three patches are trivial changes to the feature list to reflect
> > recent changes in the ACLE. Patch 4 removes most of the FMV multiversioning
> > features that don
Add target_version attribute to Common Function Attributes and update
target and target_clones documentation. Move shared detail and examples
to the Function Multiversioning page. Add target-specific details to
target-specific pages.
---
I've built and checked the info and dvi outputs. Ok for
Some architecture features have been combined under a single command
line flag, but have been assigned multiple FMV feature names with the
command line flag name enabling only a subset of these features in
the FMV specification. Remove the unsupported FMV subfeatures, and
rename the remaining
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def:
Fix "rmd"->"rdm", and add FMV to "rdma".
* config/aarch64/aarch64.cc (FEAT_RDMA): Define as FEAT_RDM.
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
It currently isn't possible to support function multiversioning features
properly in GCC without also enabling the extension in the command line
options (with the exception of features such as "rpres" that do not
require assembler support). We therefore remove unsupported features
from GCC's list
There was an assumption in some places that the aarch64_fmv_feature_data
array contained FEAT_MAX elements. While this assumption held up till
now, it is safer and more flexible to use the array size directly.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (compare_feature_masks):
Some higher priority FMV features were dependent subsets of lower
priority features. Fix this, using the new priorities specified in
https://github.com/ARM-software/acle/pull/279.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def: Reorder FMV entries.
diff --git
The first three patches are trivial changes to the feature list to reflect
recent changes in the ACLE. Patch 4 removes most of the FMV multiversioning
features that don't work at the moment, and should be entirely uncontroversial.
Patch 5 handles the remaining cases, where there's an
It would be neater if the middle end for target_clones used a target
hook for version name mangling, so we only do version name mangling
once. However, that would require more intrusive refactoring that will
have to wait till Stage 1.
I've made the changes Richard Sandiford requested, and merged
It would be neater if the middle end for target_clones used a target
hook for version name mangling, so we only do version name mangling
once. However, that would require more intrusive refactoring that will
have to wait till Stage 1.
This patch builds upon the testsuite additions in patch 1/5
On Mon, Jan 15, 2024 at 01:28:04PM +0100, Richard Biener wrote:
> On Mon, Jan 15, 2024 at 12:27 PM Andrew Carlotti
> wrote:
> >
> > This allows code to determine why a particular function is
> > multiversioned. For now, this will primarily be used to preserve
> >
These tests are not intended to designate "correct" behaviour, but are
instead intended to demonstrate current behaviour, and provide a warning
if subsequent patches might lead to compatibility issues for targets
with existing function multiversioning support.
gcc/testsuite/ChangeLog:
*
There's no functional change here, but it makes it clearer that all
three locations should be doing the same thing (aside from changes to
flag_abi_version).
gcc/cp/ChangeLog:
* mangle.cc (mangle_decl): Consistently use get_mangled_id.
diff --git a/gcc/cp/mangle.cc b/gcc/cp/mangle.cc
This patch series should have no functional change besides the mangling of some
symbol names on AArch64.
Patch 1/5 adds lots of tests to verify that existing mangling behaviour on x86
and PowerPC is unchanged.
Patch 2/5 extends DECL_FUNCTION_VERSIONED to a 2-bit enum.
Patches 3/5 and 4/5 are
When using "target" or "target_version" attributes, some parts of the
code assume that the default version has no function-specific mangling
while generating names for the resolver and ifunc. Since aarch64 now
breaks that assumption, we add an explicit workaround for this issue.
Ideally we'd
The new name better describes where it is used, and will be more
suitable when subsequent commits make further changes to this function.
gcc/ChangeLog:
* cgraph.h (create_version_clone_with_body): Rename parameter
and change default value.
* cgraphclones.cc: Rename
This allows code to determine why a particular function is
multiversioned. For now, this will primarily be used to preserve
existing name mangling quirks when subsequent commits change all
function multiversioning name mangling to use explicit target hooks.
However, this can also be used in
This adds initial support for function multiversioning on aarch64 using
the target_version and target_clones attributes. This loosely follows
the Beta specification in the ACLE [1], although with some differences
that still need to be resolved (possibly as follow-up patches).
Existing function
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
On targets that don't use the "target" attribute for multiversioning,
there is no conflict between the "target" and
On Sat, Dec 09, 2023 at 07:22:49PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > ...
>
> This is the only use of native_detect_p, so it'd be good to remove
> the field itself.
Done
> > ...
> >
> > @@ -447,6 +451,13 @@ host_detect_lo
Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with
checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead. The value of the
AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is
retained because removing it would make processing the data in
option-extensions.def
Add a terminating newline to various tests, and add missing
extensions to some test strings. The current output is broken for
options_set_4.c, so this test is left unchanged, to be fixed in a
subsequent patch.
Committed as obvious, with options_set_4.c removed compared to v1.
On Sat, Dec 09, 2023 at 06:42:17PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> The .def files are included in TM_H by:
>
> TM_H += $(srcdir)/config/aarch64/aarch64-fusion-pairs.def \
> $(srcdir)/config/aarch64/aarch64-tuning-flags.def \
> $(srcd
Results verified by running
`RUNTESTFLAGS="aarch64-ssve.exp=*" make -k -j 56 check-gcc`
before and after the change. I initally spotted the issue because the tests
were being run a nondeterministic number of time during unrelated regresison
testing.
Committed as obvious.
This adds initial support for function multiversioning on aarch64 using
the target_version and target_clones attributes. This loosely follows
the Beta specification in the ACLE [1], although with some differences
that still need to be resolved (possibly as follow-up patches).
Existing function
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
On targets that don't use the "target" attribute for multiversioning,
there is no conflict between the "target" and
Change the handling of some attribute mutual exclusions to use the
generic attribute exclusion lists, and fix some asymmetric exclusions by
adding the exclusions for always_inline after noinline or target_clones.
Aside from the new always_inline exclusions, the only change is
functionality is the
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is removed.
The only change in functionality is the
This is added to enable function multiversioning, but can also be used
directly. The interface is chosen to match that used in LLVM's
compiler-rt, to facilitate cross-compiler compatibility.
The content of the patch is derived almost entirely from Pavel's prior
contributions to
This series adds support for function multiversioning on aarch64.
Patches 1-3 are already approved, with just one minor change from the previous
version of patch 1 suggested by Richard Sandiford.
Patches 4-5 are updated based on Richard's reviews. The only major change is
replacing the
For native cpu feature detection, certain features have no entry in
/proc/cpuinfo, so have to be assumed to be present whenever the detected
cpu is supposed to support that feature.
However, the logic for this was mistakenly implemented by excluding
these features from part of
Additionally, replace all checks for the AARCH64_FL_CRYPTO bit with
checks for (AARCH64_FL_AES | AARCH64_FL_SHA2) instead. The value of the
AARCH64_FL_CRYPTO bit within isa_flags is now ignored, but it is
retained because removing it would make processing the data in
option-extensions.def
Add a terminating newline to various tests, and add missing
extensions to some test strings.
Obvious change, so I'll push it once my other option handling patches are
approved (if noone objects).
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cpunative/native_cpu_18.c: Add \+nopauth\n
Ok for master?
gcc/ChangeLog:
* config/aarch64/x-aarch64: Add missing dependencies.
diff --git a/gcc/config/aarch64/x-aarch64 b/gcc/config/aarch64/x-aarch64
index
3cf701a0a01ab00eaaafdfad14bd90ebbb1d498f..6fd638faaab7cb5bb2309d36d6dea2adf1fb8d32
100644
---
On Fri, Nov 24, 2023 at 04:22:54PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > This adds initial support for function multiversioning on aarch64 using
> > the target_version and target_clones attributes. This loosely follows
> > the Beta specification in t
On Wed, Nov 29, 2023 at 05:53:56PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > This patch adds support for the "target_version" attribute to the middle
> > end and the C++ frontend, which will be used to implement function
> > multive
On Mon, Nov 20, 2023 at 03:46:06PM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > This is added to enable function multiversioning, but can also be used
> > directly. The interface is chosen to match that used in LLVM's
> > compiler-rt, to facilitate cross-c
On Fri, Nov 17, 2023 at 11:45:16AM +0100, Marc Poulhi�s wrote:
>
> Hello,
>
> > I haven't manged to test the Ada frontend, but this patch (and the following
>
> I don't have an aarch64 setup to test, but I may be able to help with the
> issue preventing you from testing. Can you elaborate
This adds initial support for function multiversioning on aarch64 using
the target_version and target_clones attributes. This loosely follows
the Beta specification in the ACLE [1], although with some differences
that still need to be resolved (possibly as follow-up patches).
Existing function
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
On targets that don't use the "target" attribute for multiversioning,
there is no conflict between the "target" and
Change the handling of some attribute mutual exclusions to use the
generic attribute exclusion lists, and fix some asymmetric exclusions by
adding the exclusions for always_inline after noinline or target_clones.
Aside from the new always_inline exclusions, the only change is
functionality is the
This patch changes the handling of mutual exclusions involving the
target and target_clones attributes to use the generic attribute
exclusion lists. Additionally, the duplicate handling for the
always_inline and noinline attribute exclusion is removed.
The only change in functionality is the
This is added to enable function multiversioning, but can also be used
directly. The interface is chosen to match that used in LLVM's
compiler-rt, to facilitate cross-compiler compatibility.
The content of the patch is derived almost entirely from Pavel's prior
contributions to
This series adds support for function multiversioning on aarch64.
Patch 1/5 is a repost of my copy of Pavel's aarch64 cpu feature detection code
to libgcc. This is slightly refactored in a later patch, but I've preserved
this patch as-is to make the attribution clearer.
Patches 2/5 and 3/5 are
On Fri, Nov 10, 2023 at 10:34:29AM +, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > The availability of tme intrinsics was previously gated at both
> > initialisation time (using global target options) and usage time
> > (accounting for function-specific target
This is added to enable function multiversioning, but can also be used
directly. The interface is chosen to match that used in LLVM's
compiler-rt, to facilitate cross-compiler compatibility.
The content of the patch is derived almost entirely from Pavel's prior
contributions to
The availability of ls64 intrinsics and data types were determined
solely by the globally specified architecture features, which did not
reflect any changes specified in target pragmas or attributes.
This patch removes the initialisation-time guards for the intrinsics,
and replaces them with
The availability of memtag intrinsics and data types were determined
solely by the globally specified architecture features, which did not
reflect any changes specified in target pragmas or attributes.
This patch removes the initialisation-time guards for the intrinsics,
and replaces them with
The availability of tme intrinsics was previously gated at both
initialisation time (using global target options) and usage time
(accounting for function-specific target options). This patch removes
the check at initialisation time, and also moves the intrinsics out of
the header file to allow
Move SVE extension checking functionality to aarch64-builtins.cc, so
that it can be shared by non-SVE intrinsics.
gcc/ChangeLog:
* config/aarch64/aarch64-sve-builtins.cc (check_builtin_call)
(expand_builtin): Update calls to the below.
(report_missing_extension,
This series of patches fixes issues with some intrinsics being incorrectly
gated by global target options, instead of just using function-specific target
options. These issues have been present since the +tme, +memtag and +ls64
intrinsics were introduced.
Bootstrapped and regression tested on
On Thu, Oct 26, 2023 at 07:41:09PM +0100, Richard Sandiford wrote:
> Andrew Carlotti writes:
> > This patch adds support for the "target_version" attribute to the middle
> > end and the C++ frontend, which will be used to implement function
> > multiversioning in th
On Thu, Oct 19, 2023 at 07:04:09AM +, Richard Biener wrote:
> On Wed, 18 Oct 2023, Andrew Carlotti wrote:
>
> > This patch adds support for the "target_version" attribute to the middle
> > end and the C++ frontend, which will be used to implement function
> &
This is a partial patch to make the mangling of function version names
for target_clones match those generated using the target or
target_version attributes. It modifies the name of function versions,
but does not yet rename the resolved symbol, resulting in a duplicate
symbol name (and an error
This adds initial support for function multiversion on aarch64 using the
target_version and target_clones attributes. This mostly follows the
Beta specification in the ACLE [1], with a few diffences that remain to
be fixed:
- Symbol mangling for target_clones differs from that for target_version
This patch adds support for the "target_version" attribute to the middle
end and the C++ frontend, which will be used to implement function
multiversioning in the aarch64 backend.
Note that C++ is currently the only frontend which supports
multiversioning using the "target" attribute, whereas the
This series adds support for function multiversioning on aarch64. There are a
few minor issues in patch 2/3, that I intend to fix in future versions or
follow-up patches. I also have some open questions about the correctness of
existing function multiversioning implementations [1], that could
Pushed as obvious.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_test_fractional_cost):
Test <= instead of testing < twice.
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
On Thu, Jul 20, 2023 at 09:37:14AM +0200, Richard Biener wrote:
> On Thu, Jul 20, 2023 at 8:49 AM Richard Sandiford via Gcc-patches
> wrote:
> >
> > Andrew Carlotti writes:
> > > Updated patch to fix the fp16 intrinsic pragmas, and pushed to master.
> > >
On Wed, Jul 19, 2023 at 07:35:26PM +0100, Ramana Radhakrishnan wrote:
> On Wed, Jul 19, 2023 at 5:44 PM Andrew Carlotti via Gcc-patches
> wrote:
> >
> > Updated patch to fix the fp16 intrinsic pragmas, and pushed to master.
> > OK to backport to GCC 13?
> >
>
Updated patch to fix the fp16 intrinsic pragmas, and pushed to master.
OK to backport to GCC 13?
Many intrinsics currently depend on both an architecture version and a
feature, despite the corresponding instructions being available within
GCC at lower architecture versions.
LLVM has already
On Tue, Jun 27, 2023 at 07:23:32AM +0100, Richard Sandiford wrote:
> Andrew Carlotti via Gcc-patches writes:
> > Many intrinsics currently depend on both an architecture version and a
> > feature, despite the corresponding instructions being available within
> > GCC at lower
gcc/ChangeLog:
* doc/optinfo.texi: Fix "steam" -> "stream".
diff --git a/gcc/doc/optinfo.texi b/gcc/doc/optinfo.texi
index
b91bba7bd10470b17ca5190688beee06ad3b87ab..5e8c97ef118786e68b7e46f3c802154cb9b57b83
100644
--- a/gcc/doc/optinfo.texi
+++ b/gcc/doc/optinfo.texi
@@ -100,7 +100,7 @@ that
Many intrinsics currently depend on both an architecture version and a
feature, despite the corresponding instructions being available within
GCC at lower architecture versions.
LLVM has already removed these explicit architecture version
dependences; this patch does the same for GCC, as well as
On Thu, Feb 23, 2023 at 11:39:51AM -0500, Andrew MacLeod via Gcc-patches wrote:
>
>
> Inheriting from operator_mult is also going to be hazardous because it also
> has an op1_range and op2_range...� you should at least define those and
> return VARYING to avoid other issues.� Same thing
or build_cltz_expr (and adjusts testcases
> accordingly). I might have incorporated it into an earlier patch in this
> series, if I hadn't already pushed that earlier patch.
>
> Is this OK to leave in master now?
>
> Thanks,
> Andrew
>
> On Thu, Dec 22, 2022 at 05:4
). I might have incorporated it into an earlier patch in this
series, if I hadn't already pushed that earlier patch.
Is this OK to leave in master now?
Thanks,
Andrew
On Thu, Dec 22, 2022 at 05:43:21PM +, Andrew Carlotti via Gcc-patches wrote:
> Bootstrapped and regression tested on aarc
Bootstrapped and regression tested on aarch64-unknown-linux-gnu and
x86_64-pc-linux-gnu - ok to merge?
gcc/ChangeLog:
* tree-ssa-loop-niter.cc (build_popcount_expr): Add IFN support.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/pr86544.C: Add .POPCOUNT to tree scan regex.
1 - 100 of 133 matches
Mail list logo
