Ping.
And updated the patch to reject cases that we don't expect or can handle
cleanly for now.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
* gimple-range-op.h (gimple_range_op_handler): Add mayb
Ping,
And updating the hook.
There are no new test as new correctness tests were added to the mid-end and
the existing codegen tests for this already exist.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
Ping,
And updated the hook to allow to differentiate between ISAs.
As Andy said before initializing a ranger instance is cheap but not free, and if
the intention is to call it often during a pass it should be instantiated at
pass startup and passed along to the places that need it. This is a big
> Hi!
>
> On Sun, Mar 05, 2023 at 03:33:40PM -0600, Segher Boessenkool wrote:
> > On Sun, Mar 05, 2023 at 08:43:20PM +, Tamar Christina wrote:
> > Yes, *look* better: I have seen no proof or indication that this would
>
> ("looks", I cannot type, sorry)
>
> > actually generate better code, n
Hi All,
When doing an emergency dump the cfg output dumps are corrupted because the
ending "}" is missing.
Normally when the pass manager finishes it would call finish_graph_dump_file to
produce this. This is called here because each pass can dump multiple digraphs.
However during an emergency
> -Original Message-
> From: Richard Sandiford
> Sent: Wednesday, March 8, 2023 9:18 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 4/4]AArch64 Update div-bitmask to implement new
> optab instead
Hi All,
The testcase
typedef unsigned int vec __attribute__((vector_size(32)));
vec
f3 (vec a, vec b, vec c)
{
vec d = a * b;
return d + ((c + d) >> 1);
}
shows a case where we don't want to form an FMA due to the MUL not being single
use. In this case to form an FMA we have to redo the MUL
Cheers,
Thanks! I'll way for him to come back then 😊
Thanks,
Tamar
> -Original Message-
> From: Aldy Hernandez
> Sent: Wednesday, March 8, 2023 8:57 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; amacl...@redhat.com
> Subject: Re: [PATCH 2/4][ranger]: Add range-ops for wi
Hi,
Here's the respun patch.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR target/108583
* target.def (preferred_div_as_shifts_over_mult): New.
* doc/tm.texi.in: Document it.
* doc/tm.texi: Regene
> >> As Andrew has been advising on this one, I'd prefer for him to review it.
> >> However, he's on vacation this week. FYI...
> >>
> >> Aldy
> >>
> >> On Mon, Mar 6, 2023 at 12:22 PM Tamar Christina
> >> wrote:
> >>> Ping.
> >>>
> >>> And updated the patch to reject cases that we don't expect o
Hi All,
I previously made the test generic, but there's no list
of targets that support integer MLA, and so it's not
really feasible for me to make this generic.
As such I've moved it to be AArch64 only.
committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tests
Hi,
Yes I hope to upstream it this year. I'm busy cleaning up a new version of the
patch which and hope to send it up for review again next week if all tests pass.
Cheers,
Tamar
From: juzhe.zh...@rivai.ai
Sent: Monday, May 15, 2023 6:20 AM
To: gcc-patches
Cc: rguenther ; Tamar Christina ;
Ri
Hi All,
James and I have been investigating this regression and have tracked it down to
register allocation.
I have create a new PR with our findings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98782 but unfortunately
we don't know how to proceed.
This does seem like a genuine bug in RA. It
Hi All,
This adds implementation for the optabs for complex operations. With this the
following C code:
void g (float complex a[restrict N], float complex b[restrict N],
float complex c[restrict N])
{
for (int i=0; i < N; i++)
c[i] = a[i] * b[i];
}
generates
NEON:
Hi All,
g:87301e3956d44ad45e384a8eb16c79029d20213a and
g:ee4c4fe289e768d3c6b6651c8bfa3fdf458934f4 changed the intrinsics to be
proper RTL but accidentally ended up creating a regression because of the
ordering in the RTL pattern.
The existing RTL that combine should try to match to remove the vec
Hi All,
Previously the SLP pattern matcher was using STMT_VINFO_SLP_VECT_ONLY as a way
to dissolve the SLP only patterns during SLP cancellation. However it seems
like the semantics for STMT_VINFO_SLP_VECT_ONLY are slightly different than what
I expected.
Namely that the non-SLP path can still u
Hi Honza and Martin,
As explained in PR98782 the problem is that the behavior of IRA is quite tightly
bound to the frequencies that IPA puts out. With the change introduced in
g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92 some, but not all edge predictions
changed. This introduces a local problem w
Hi Richi,
The attached testcase ICEs due to a couple of issues.
In the testcase you have two SLP instances that share the majority of their
definition with each other. One tree defines a COMPLEX_MUL sequence and the
other tree a COMPLEX_FMA.
The ice happens because:
1. the refcounts are wrong,
Ps. The code in comment is needed, but was commented out due to the early free
issue described in the patch.
Thanks,
Tamar
> -Original Message-
> From: Tamar Christina
> Sent: Friday, February 19, 2021 2:42 PM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: [PATCH]
Hi Richi,
The attached testcase shows a bug where two nodes end up with the same pointer.
During the loop that analyzes all the instances
in optimize_load_redistribution_1 we do
if (value)
{
SLP_TREE_REF_COUNT (value)++;
SLP_TREE_CHILDREN (root)[i] = value;
Hi Richi,
This is an updated patch with your suggestion.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR tree-optimization/99220
* tree-vect-slp.c (optimize_load_redistribution_1): Remove
node from cache wh
> -Original Message-
> From: Christophe Lyon
> Sent: Wednesday, February 24, 2021 2:17 PM
> To: Richard Biener
> Cc: Tamar Christina ; nd ; gcc
> Patches
> Subject: Re: [PATCH v2] middle-end slp: fix sharing of SLP only patterns.
>
> On Wed, 24 Feb 2021 at 09:38, Richard Biener wrote:
Hi All,
This patch disables the test for PR99149 on Big-endian
where for standard AArch64 the patterns are disabled.
Regtested on aarch64-none-linux-gnu and no issues.
Committed under the obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/99149
* g++.dg/
Hi All,
The given testcase shows that one of the children of the complex MUL contains a
PHI node. This results in the vectorizer having a child that's (nil).
The pattern matcher handles this correctly, but optimize_load_redistribution_1
needs to not traverse/inspect the NULL nodes.
This however
Hi All,
I believe PR101750 to be a testism. The reduced case accesses h[0] but h is
uninitialized and so the changes added in r12-2523 makes the compiler realize
this and replaces the code with a trap.
This fixes the case by just making the variable static.
regtested on aarch64-none-linux-gnu an
Hi All,
The build is broken since a3d3e8c362c2 since it's deleted the ability to pass
vec<> by value and now much be past by reference.
However some language hooks used by AArch64 were not updated and breaks the
build on AArch64. This patch updates these hooks.
However most of the changes are g
Hi All,
Consider the following case
#include
uint64_t
test4 (uint8x16_t input)
{
uint8x16_t bool_input = vshrq_n_u8(input, 7);
poly64x2_t mask = vdupq_n_p64(0x0102040810204080UL);
poly64_t prodL = vmull_p64((poly64_t)vgetq_lane_p64((poly64x2_t)bool_input,
0),
Hi All,
As the vectorizer has improved over time in capabilities it has started
over-vectorizing. This has causes regressions in the order of 1-7x on libraries
that Arm produces.
The vector costs actually do make a lot of sense and I don't think that they are
wrong. I think that the costs for t
Hi All,
This patch gets CSE to re-use constants already inside a vector rather than
re-materializing the constant again.
Basically consider the following case:
#include
#include
uint64_t
test (uint64_t a, uint64x2_t b, uint64x2_t* rt)
{
uint64_t arr[2] = { 0x0942430810234076UL, 0x0942430810
Hi All,
This patch adds extended costing to cost the creation of constants and the
manipulation of constants. The default values provided are based on
architectural expectations and each cost models can be individually tweaked as
needed.
The changes in this patch covers:
* Construction of PARAL
Hi All,
The following example
void f10(double * restrict z, double * restrict w, double * restrict x,
double * restrict y, int n)
{
for (int i = 0; i < n; i++) {
z[i] = (w[i] > 0) ? x[i] + w[i] : y[i] - w[i];
}
}
generates currently:
ld1dz1.d, p1/z, [x1, x5,
Hi All,
The following example
void f5(float * restrict z0, float * restrict z1, float *restrict x,
float * restrict y, float c, int n)
{
for (int i = 0; i < n; i++) {
float a = x[i];
float b = y[i];
if (a > b) {
z0[i] = a + b;
if (a > c)
Hi All,
The following example:
void f11(double * restrict z, double * restrict w, double * restrict x,
double * restrict y, int n)
{
for (int i = 0; i < n; i++) {
z[i] = (w[i] > 0) ? w[i] : y[i];
}
}
Generates currently:
ptrue p2.b, all
ld1dz0.d, p
Hi All,
The following loop does a conditional reduction using an add:
#include
int32_t f (int32_t *restrict array, int len, int min)
{
int32_t iSum = 0;
for (int i=0; i= min)
iSum += array[i];
}
return iSum;
}
for this we currently generate:
mov z1.b, #0
mo
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, August 31, 2021 4:14 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and oper
> -Original Message-
> From: Richard Sandiford
> Sent: Tuesday, August 31, 2021 5:07 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64: Add better costing for vector constants
> and op
Hi,
Attached is the respun version of the patch,
> >>
> >> Wouldn't a target need to re-check if lanes are NaN or denormal if
> >> after a SFmode lane operation a DFmode lane operation follows? IIRC
> >> that is what usually makes punning "integer" vectors as FP vectors costly.
I don't believe
Hello,
> where logical_inverted is somewhat contradicting using zero_one_valued
> instead of truth_valued_p (I think the former might not work for vector
> booleans?).
>
> In the end I'd prefer zero_one_valued_p but avoiding inverse_conditions_p
> would be nice.
>
> Richard.
It's not pretty but
Hi All,
This adds support for using scalar fneg on the V1DF type.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (negv1df2): New.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/simd/
Hi All,
GCC currently recognizes some of these for signed but not unsigned types.
It also has trouble dealing with casts in between because these are handled
by the fold machinery.
This moves the pattern detection to match.pd instead.
We fold e.g.:
uint32_t min1_32u(uint32_t a, uint32_t b, uint
Hi All,
The following testcase:
int zoo1 (int a, int b, int c, int d)
{
return (a > b ? c : d) & 1;
}
gets de-optimized by the front-end since somewhere around GCC 4.x due to a fix
that was added to fold_binary_op_with_conditional_arg.
The folding is supposed to succeed only if we have folde
Hi All,
Often times when a check_function_body check fails it can be quite hard to
figure out why as no additional information is provided.
This changes it so that on failures it prints out the regex expression it's
using and the text it's comparing against to the verbose log.
This makes it much
Hi All,
This is an RFC to figure out how to deal with targets that don't have native
comparisons against QImode values.
Booleans, at least in C99 and higher are 0-1 valued. This means that we only
really need to test a single bit. However in RTL we no longer have this
information available and
Hi All,
This adds additional recognition of & 1 into the tbz/tbnz pattern.
Concretely with the mid-end changes this changes
void g1(bool x)
{
if (__builtin_expect (x, 0))
h ();
}
from
tst w0, 255
bne .L7
to
tbnzw0, #0, .L5
This pattern occurs ~120,0
Hi All,
In plenty of image and video processing code it's common to modify pixel values
by a widening operation and then scale them back into range by dividing by 255.
e.g.:
x = y / (2 ^ (bitsize (y)/2)-1
This patch adds a new target hook can_special_div_by_const, similar to
can_vec_perm whi
Hi All,
In plenty of image and video processing code it's common to modify pixel values
by a widening operation and then scale them back into range by dividing by 255.
This patch adds an named function to allow us to emit an optimized sequence
when doing an unsigned division that is equivalent to
Hi All,
This adds an RTL pattern for when two NARROWB instructions are being combined
with a PACK. The second NARROWB is then transformed into a NARROWT.
For the example:
void draw_bitmap1(uint8_t* restrict pixel, uint8_t level, int n)
{
for (int i = 0; i < (n & -16); i+=1)
pixel[i] += (p
Hi All,
This adds an implementation for the new optab for unsigned pow2 bitmask for
AArch64.
The implementation rewrites:
x = y / (2 ^ (sizeof (y)/2)-1
into e.g. (for bytes)
(x + ((x + 257) >> 8)) >> 8
where it's required that the additions be done in double the precision of x
such that
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 23, 2022 5:30 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64 Add support for neg on v1df
>
> Tamar Christina
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 23, 2022 5:43 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64 Extend tbz pattern to allow SI to SI
> extensions
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 23, 2022 6:04 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: Re: [PATCH 2/2]AArch64 Add support for neg on v1df
>
> Tamar Christina
Hi All,
This adds a match.pd rule that can fold right shifts and bit_field_refs of
integers into just a bit_field_ref by adjusting the offset and the size of the
extract and adds an extend to the previous size.
Concretely turns:
#include
unsigned int foor (uint32x4_t x)
{
return x[1] >> 16
Hi All,
Similar to the 1/2 patch but adds additional back-end specific folding for if
the register sequence was created as a result of RTL optimizations.
Concretely:
#include
unsigned int foor (uint32x4_t x)
{
return x[1] >> 16;
}
generates:
foor:
umovw0, v0.h[3]
ret
> -Original Message-
> From: Richard Biener
> Sent: Friday, September 23, 2022 8:54 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ;
> juzhe.zh...@rivai.ai
> Subject: RE: [PATCH]middle-end Add optimized float
> -Original Message-
> From: Richard Biener
> Sent: Friday, September 23, 2022 9:10 AM
> To: Tamar Christina
> Cc: Andrew Pinski ; nd ; gcc-
> patc...@gcc.gnu.org
> Subject: RE: [PATCH]middle-end simplify complex if expressions where
> comparisons are inverse of one another.
>
> On Fri,
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Tamar
> Christina via Gcc-patches
> Sent: Friday, September 23, 2022 9:14 AM
> To: Richard Biener
> Cc: Richard Sandiford ; nd ;
> Tamar Christina via Gcc-patches
gt; On Fri, Sep 23, 2022 at 4:43 AM Tamar Christina via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> > Hi All,
> >
> > This adds a match.pd rule that can fold right shifts and
> > bit_field_refs of integers into just a bit_field_ref by adjusting the
> > off
> > This pattern occurs more than 120,000 times in SPECCPU 2017 and so is quite
> > common.
> How does this help a target?
So the idea is to communicate that only the bottom bit of the value is relevant
and not the entire value itself.
> Why does RTL nonzerop bits not recover thisinformation a
> Maybe the target could use (subreg:SI (reg:BI ...)) as argument. Heh.
But then I'd still need to change the expansion code. I suppose this could
prevent the issue with changes to code on other targets.
> > > We have undocumented addcc, negcc, etc. patterns, should we have aandcc
> > > pattern
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 26, 2022 1:43 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com;
> Richard Sandiford
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argu
> -Original Message-
> From: Jeff Law
> Sent: Saturday, September 24, 2022 8:38 PM
> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> Cc: nd ; rguent...@suse.de
> Subject: Re: [PATCH 1/2]middle-end Fold BIT_FIELD_REF and Shifts into
> BIT_FIELD_REFs alone
>
>
> On 9/23/22 05:42, Tamar Chr
> -Original Message-
> From: Richard Biener
> Sent: Thursday, September 29, 2022 10:41 AM
> To: Richard Sandiford
> Cc: Jeff Law ; Tamar Christina
> ; gcc-patches@gcc.gnu.org; nd
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> branches, give hint if argument is a
> -Original Message-
> From: Gcc-patches bounces+tamar.christina=arm@gcc.gnu.org> On Behalf Of Richard
> Biener via Gcc-patches
> Sent: Thursday, September 29, 2022 12:09 PM
> To: Tamar Christina via Gcc-patches
> Cc: Richard Sandiford ; nd
> Subject: Re: [P
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 30, 2022 9:29 AM
> To: Tamar Christina
> Cc: Richard Biener ; Tamar Christina via Gcc-patches
> ; nd ; Jeff Law
>
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> -Original Message-
> From: Richard Sandiford
> Sent: Friday, September 30, 2022 9:49 AM
> To: Tamar Christina
> Cc: Richard Biener ; Tamar Christina via Gcc-patches
> ; nd ; Jeff Law
>
> Subject: Re: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> -Original Message-
> From: Richard Biener
> Sent: Friday, September 30, 2022 11:17 AM
> To: Tamar Christina
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ; Jeff Law
>
> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
> -Original Message-
> From: Richard Biener
> Sent: Friday, September 30, 2022 12:53 PM
> To: Tamar Christina
> Cc: Richard Sandiford ; Tamar Christina via
> Gcc-patches ; nd ; Jeff Law
>
> Subject: RE: [PATCH 1/2]middle-end: RFC: On expansion of conditional
Hi All,
This adds a vect_float requirements to this tests to stop them from running on
targets that don't support float vectorization.
Regtested on aarch64-none-linux-gnu and no issues.
Ok for master? and GCC 11?
I would normally have committed this as trivial but since I need GCC 11
too I've s
Hi All,
These testcases declare requiring vect_int which sparc declares as well however
sparc doesn't have an optab to vectorize comparisons so these testcases fail to
vectorize and so the tests fail.
As such best coure of action is to just skip them on sparc as comparisons are
somewhat expected
Hi All,
As the discussion in the PR pointed out the RTL we have for the REDUC_PLUS
patterns are wrong. The UNSPECs are modelled as returning a vector and then
in an expand pattern we emit a vec_select of the 0th element to get the scalar.
This is incorrect as the instruction itself already only
Hi All,
As pointed out in PR105095 these tests weren't running, mainly because the .exp
file contains a filter on the first character so it can distinguish between
fast-math-bb-slp-* and fast-math-*, my test started with `c` and so didn't get
found.
This patch adds `c` to the list of filters and
Hi All,
These tests are reduced from a C program and use gcc vector extensions and so
aren't endianness agnostic. As such skip them on BE.
Regtested on aarch64_be-none-linux-gnu and no issues.
committed under the GCC obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
* gcc.target/aa
Hi All,
The LS64 intrinsics used a machinery that's not safe to use unless being
called from a pragma instantiation.
This moves the initialization code to a new pragma for arm_acle.h.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
I didn't add the testcase from the PR as it's 6
Hi All,
I accidentally left in an slp1 check in the vect test which showed up as
UNRESOLVED and had missed it in the sum file. This deletes that line.
Committed under obvious rule.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR testsuite/105196
* gcc.dg/vect/complex/fast-math-compl
Hi All,
Previously ifcvt used to enforce that a mask A and the inverse of said mask be
represented as ~A. So for the masks
_25 = _6 != 0;
_44 = _4 != 0;
ifcvt would produce for an operation requiring the inverse of said mask
_26 = ~_25;
_43 = ~_44;
but now that VN is applied to the ent
Ping x3
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:11 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; 'ni...@redhat.com' ;
> Kyrylo Tkachov
> Subject: RE: [3/3 PATCH][AArch32] use canonical ordering for comple
Ping x3.
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:11 AM
> To: Richard Sandiford
> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> ; Marcus Shawcroft
> ; Kyrylo Tkachov
> Subject: RE: [2/3 PATCH]AArch64 use canonical ordering for complex mul,
>
Ping x3
> -Original Message-
> From: Tamar Christina
> Sent: Tuesday, January 11, 2022 7:10 AM
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Ramana Radhakrishnan
> ; Richard Earnshaw
> ; ni...@redhat.com; Kyrylo Tkachov
>
> Subject: RE: [PATCH][AArch32]: correct usdot-product RTL patterns.
>
Hi All,
This is a backport of the GCC 12 patch backporting only the correctness part of
the fix. This also backports two small helper functions and documentation
update on the optabs.
The patch boosts the analysis for complex mul,fma and fms in order to ensure
that it doesn't create an incorrec
Hi All,
GCC 11 handled negations rather differently than GCC 12. This difference
caused the previous backport to regress some of the conjugate cases that it
used to handle before. The testsuite in GCC 11 wasn't as robust as that in
master so it didn't catch it.
The second patch in this series b
Hi All,
The GCC 12 testsuite for complex numbers pattern recognition is a lot more
exhaustive than the GCC 11 one. This backports the testsuite to GCC 11 so
any further changes to the branch prevents regressions.
Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regres
Hi All,
Both sides of the VEC_PERM_EXPR need to be a MULT but the check
was accidentally checking if both sides are a mul.
The FMS case would be handled by the validate_multiplication but
this makes the requirement more explicit and we exit earlier.
Bootstrapped Regtested on aarch64-none-linux-g
Hi All,
Apologies, I got dinged by the i386 regressions bot for a test I didn't have in
my tree at the time I made the previous patch. The bot was telling me that FMA
stopped working after I strengthened the FMA check in the previous patch.
The reason is that the check is slightly early. The fi
Hi All,
Newlib changed ctype.h recently[1] by moving the short labels from ctype.h intro
the private namespace in ctype_.h. This broke embedded builds due to them no
longer being found. Instead they now expose the long names to match glibc.
This patch now uses the short or long names depending
Ping
> -Original Message-
> From: Tamar Christina
> Sent: Friday, November 12, 2021 7:31 AM
> To: Jakub Jelinek
> Cc: Jonathan Wakely ; Richard Biener
> ; gcc-patches@gcc.gnu.org; nd
> Subject: RE: [PATCH] middle-end: fix de-optimizations with bitclear patterns
> on signed values
>
>
>
ize right shift rounding narrowing
>
> Ping.
>
> > -Original Message-
> > From: Gcc-patches > bounces+tamar.christina=arm....@gcc.gnu.org> On Behalf Of Tamar
> > Christina via Gcc-patches
> > Sent: Friday, November 12, 2021 12:08 PM
> > To: gcc-patc
Hi Jakub,
> -Original Message-
> From: Jakub Jelinek
> Sent: Thursday, November 25, 2021 8:19 AM
> To: Richard Biener
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org
> Subject: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> simplification [PR103417]
>
> Hi!
>
> The foll
> -Original Message-
> From: Jakub Jelinek
> Sent: Thursday, November 25, 2021 8:39 AM
> To: Tamar Christina
> Cc: Richard Biener ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> simplification [PR103417]
>
> On Thu, Nov 25, 2021
> -Original Message-
> From: Jakub Jelinek
> Sent: Thursday, November 25, 2021 8:19 AM
> To: Richard Biener
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org
> Subject: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> simplification [PR103417]
>
> Hi!
>
> The following testc
> -Original Message-
> From: Jakub Jelinek
> Sent: Thursday, November 25, 2021 9:53 AM
> To: Richard Biener
> Cc: Tamar Christina ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] match.pd: Fix up the recent bitmask_inv_cst_vector_p
> simplification [PR103417]
>
> On Thu, Nov 25, 2021
Hi All,
CSE uses equivalence classes to keep track of expressions that all have the same
values at the current point in the program.
Normal equivalences through SETs only insert and perform lookups in this set but
equivalence determined from comparisons, e.g.
(insn 46 44 47 7 (set (reg:CCZ 17 fl
> -Original Message-
> From: Richard Biener
> Sent: Monday, November 29, 2021 9:02 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@tachyum.com;
> Richard Sandiford
> Subject: Re: [PATCH]middle-end cse: Make sure duplicate elements are not
> entered into the equivalence
Hi All,
Following the previous bugfix this addresses the cosmetic and test issues.
The vector tests are moved to vect and the scalar are left where they are.
Bootstrapped Regtested x86_64-pc-linux-gnu and no regressions.
Tested with -m32/-mno-sse and no issues.
Ok for master?
Thanks,
Tamar
gc
Hi All,
This updates the testcase bic-bitmask-18.c to seach for " = 0;" as an expression
so it doesn't match any other partial expressions.
Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu (with and without -m32) and no regressions.
Committed under the obvious rule.
Thanks,
Tamar
gcc/t
Hi All,
He's a respin of the patch which doesn't change the complexity of insert.
Richard S, since you approved the original patch could you take a look at this
fix.
---
Hi All,
CSE uses equivalence classes to keep track of expressions that all have the same
values at the current point in the
> This hashing looks unnecessarily complex. The values we're hashing are
> vector SSA_NAMEs, so I think we should be able to hash and compare them
> as a plain pair of pointers.
>
> The type could then be std::pair and the hashing could be done using
> pair_hash from hash-traits.h.
>
Fancy.. TI
Hi,
As discussed off-line this can only happen with a V1 mode, so here's a much
simpler patch.
Bootstrapped Regtested on aarch64-none-linux-gnu,
x86_64-pc-linux-gnu and no regressions.
Ok for master?
Thanks,
Tamar
gcc/ChangeLog:
PR rtl-optimization/103404
* cse.c (find_sets_
> -Original Message-
> From: Richard Biener
> Sent: Monday, September 26, 2022 11:28 AM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; jeffreya...@gmail.com;
> ebotca...@adacore.com
> Subject: Re: [PATCH]middle-end fix floating out of constants in conditionals
>
> On Fri, 23 S
function arguments using a
> paradoxical subreg when beneficial.
>
> On Fri, May 13, 2022 at 10:14 AM Tamar Christina via Gcc-patches patc...@gcc.gnu.org> wrote:
> >
> > Hi All,
> >
> > The PROMOTE_MODE always promotes 8 and 16-bit parameters to 32-bits.
> > This prom
>
> The type of the expression should be available via the mode and the
> signedness, no? So maybe to avoid having both RTX and TREE on the target
> hook pass it a wide_int instead for the divisor?
>
Done.
Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues.
Ok
101 - 200 of 597 matches
Mail list logo
