https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #13 from Wilco ---
(In reply to Bernd Edlinger from comment #12)
> Created attachment 46863 [details]
> untested patch
>
> That was easy :-)
> I have been there before...
Great! That bootstraps successfully now.
||2019-09-11
CC||wilco at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Wilco ---
(In reply to Christophe Lyon from comment
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
The following example shows that register allocation of types which require
multiple registers is quite non-optimal:
#include
#include
void neon_transform_nada(const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91753
--- Comment #4 from Wilco ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Wilco from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > lower-subreg should have be able to help here. I wonder why it did not
> > > .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91766
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #16 from Wilco ---
(In reply to Richard Earnshaw from comment #15)
> So is this now fixed?
On trunk yes. This is quite a nasty alias bug in CSE, so it will need to be
backported.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #18 from Wilco ---
(In reply to Richard Earnshaw from comment #17)
> So do we have a testcase that shows the problem on older compilers?
Yes, the same testcase shows the same incorrect substitution in older
compilers. I tried GCC9, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91776
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #20 from Wilco ---
(In reply to Richard Earnshaw from comment #19)
> (In reply to Wilco from comment #18)
> > (In reply to Richard Earnshaw from comment #17)
> > > So do we have a testcase that shows the problem on older compilers?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91708
--- Comment #22 from Wilco ---
(In reply to Richard Earnshaw from comment #21)
> But dropping in a char* will give a more restrictive alias set, so that
> isn't wrong, even if it is suboptimal
The alias set could be anything given CSE changes on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738
--- Comment #2 from Wilco ---
Author: wilco
Date: Wed Sep 18 19:52:09 2019
New Revision: 275907
URL: https://gcc.gnu.org/viewcvs?rev=275907&root=gcc&view=rev
Log:
[ARM] Add logical DImode expanders
We currently use default mid-end expanders for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91738
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #7 from Wilco ---
Fixed
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Wilco ---
Fixed
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Since GCC7 alignas no longer works correctly if the requested alignment is
larger than MAX_STACK_ALIGNMENT (which is 8 or 16 on most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89357
Wilco changed:
What|Removed |Added
Summary|alignas for automatic |[7/8/9/10
|variables with alig
||wilco at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #17 from Wilco ---
Not a GCC bug, just a gmp configuration oddity.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #29 from Wilco ---
(In reply to Jiu Fu Guo from comment #28)
> For these kind of small loops, it would be acceptable to unroll in GIMPLE,
> because register pressure and instruction cost may not be major concerns;
> just like "cunrol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #32 from Wilco ---
(In reply to Segher Boessenkool from comment #31)
> Gimple passes know a lot about machine details, too.
>
> Irrespective of if this is "low-level" or "high-level", it should be done
> earlier than it is now. It s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #34 from Wilco ---
(In reply to rguent...@suse.de from comment #30)
> On Fri, 11 Oct 2019, wilco at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
> >
> > --- Comment #29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42575
Wilco changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
||2019-10-14
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Wilco ---
Confirmed. AArch64 gets this right so we should emit efficient code on Arm too.
||2019-10-16
CC||wilco at gcc dot gnu.org
Target Milestone|--- |10.0
Summary|ice in gen_movsi, at|[10 regression][ARM] ice in
|config/arm/arm.md:5378 |gen_movsi, at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81356
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83491
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83491
--- Comment #3 from Wilco ---
(In reply to Jakub Jelinek from comment #2)
> There are multiple bugs:
> 1) the callers of execute_cse_reciprocals_1 ensure that def is SSA_NAME, so
> using:
> /* If this is a square (x * x), we should check whethe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83491
--- Comment #6 from Wilco ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg01357.html
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Wilco ---
Latest trunk generates:
.L7:
ldr s2, [x1, 4]!
ldr q1, [x0], 124
mla v0.4s, v1.4s, v2.s[0]
cmp x0, x2
bne .L7
So
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726
--- Comment #3 from Wilco ---
This is related with PR82964/82974, looks like same underlying issue. I have a
patch which changes the constraint, and that fixes this issue too. It's not
obvious to me whether legitimate_constant_p should be a subse
||2018-01-09
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Wilco ---
Note r255230 introduces 'y' and 'z' operand printing specifiers to solve this
issue, however they are no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726
--- Comment #6 from Wilco ---
(In reply to Steve Ellcey from comment #4)
> This looks like the same thing as PR 83632.
It likely is, I don't see it failing with my patch. Older compilers don't
appear to like the Fortran syntax...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82392
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79041
--- Comment #15 from Wilco ---
Author: wilco
Date: Wed Jan 17 16:31:42 2018
New Revision: 256800
URL: https://gcc.gnu.org/viewcvs?rev=256800&root=gcc&view=rev
Log:
[AArch64] PR82964: Fix 128-bit immediate ICEs
This fixes PR82964 which reports I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82964
--- Comment #2 from Wilco ---
Author: wilco
Date: Wed Jan 17 16:31:42 2018
New Revision: 256800
URL: https://gcc.gnu.org/viewcvs?rev=256800&root=gcc&view=rev
Log:
[AArch64] PR82964: Fix 128-bit immediate ICEs
This fixes PR82964 which reports IC
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #3 from Wilco ---
(In reply to Andreas Schwab from comment #0)
> $ gcc/gfortran -Bgcc/ ../../gcc/gcc/testsuite/gfortran.dg/pdt_26.f03
> -mabi=lp64 -O3 -g -S
Fixed by r256800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83726
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82964
Wilco changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82964
--- Comment #5 from Wilco ---
Author: wilco
Date: Thu Jan 18 16:37:44 2018
New Revision: 256854
URL: https://gcc.gnu.org/viewcvs?rev=256854&root=gcc&view=rev
Log:
[AArch64] Fix fp16 test failures after PR82964 fix
This fixes test failures in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #7 from Wilco ---
(In reply to H.J. Lu from comment #6)
> (In reply to Wilco from comment #5)
> > Note there are other optimizations which can block a tailcall, for example:
> >
> > void *f (void *p) { return __builtin_strchr (p, 0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #9 from Wilco ---
(In reply to Jakub Jelinek from comment #8)
> That just means r240568 caused another regression.
> Again, on various targets strchr is efficient, just on a few ones it is not
> and the change was unfortunately done g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #12 from Wilco ---
(In reply to H.J. Lu from comment #10)
> (In reply to Wilco from comment #9)
> > (In reply to Jakub Jelinek from comment #8)
> > > That just means r240568 caused another regression.
> > > Again, on various targets s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #15 from Wilco ---
(In reply to H.J. Lu from comment #13)
> (In reply to Wilco from comment #12)
>
> > >
> > > Do you have data to show that?
> >
> > Yes, on x64 I get these timings for a simple function containing just the
> > lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #14 from Wilco ---
(In reply to Jakub Jelinek from comment #11)
> No matter what, I don't see how you could use much common infrastructure
> here.
> Say if the tailcall pass sees strlen (something) + something being returned,
> it cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81657
--- Comment #17 from Wilco ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Wilco from comment #15)
> > I don't think it's safe to compare different benchmark results like that.
> > But yes the kernel for both should be very simila
||2018-01-19
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Wilco ---
Commit related to this:
commit a1b0b75cfc4f82162fc7e9b1f7255c98359a1078
Author: pinskia
Date: Wed Feb 1 18:30:50 2017 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #25 from Wilco ---
(In reply to Qing Zhao from comment #24)
> From the above, we can see:
> even with n is as big as 20, inlined version is much faster than the
> non-inlined version, both on aarch64 (no hardware string compare in
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
Initial performance results for PR78809 suggest that partial inlining of strcmp
may be beneficial. We could inline the first character comparison before
calling strcmp:
if ((res = s[0] - t[0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84029
--- Comment #2 from Wilco ---
(In reply to Richard Biener from comment #1)
> If we know the length of either argument and the other argument is properly
> aligned we can do a 2, 4 or 8 byte compare upfront. Not sure how often that
> happens (esp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #29 from Wilco ---
(In reply to Qing Zhao from comment #28)
> >
> > I don't think this is a good test. Repeatedly calling strcmp with the same
> > inputs is not something real code does, especially when the string matches
> > exactl
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
PR59461 changed nonzero_bits1 incorrectly for subregs:
/* On many CISC machines, accessing an object in a wider mode
causes the high-order bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #31 from Wilco ---
(In reply to Qing Zhao from comment #30)
> (in reply to Wilco from comment #29)
> >
> > The new test is better, however it uses i % 15 which means an expensive
> > division by constant every loop iteration. It's be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
--- Comment #5 from Wilco ---
(In reply to Eric Botcazou from comment #3)
> > PR59461 changed nonzero_bits1 incorrectly for subregs:
> >
> > /* On many CISC machines, accessing an object in a wider mode
> > causes the high
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Wilco changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
--- Comment #15 from Wilco ---
(In reply to Eric Botcazou from comment #10)
> > The addition is performed on the full 32-bit register, so this obviously
> > means that the top 24 bits have an undefined value.
>
> Not if the entire registers have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84071
--- Comment #19 from Wilco ---
(In reply to Eric Botcazou from comment #16)
> > Also I wonder whether this means AArch64 should set it since targets like
> > MIPS
> > and Sparc already set it.
>
> There seems to be a good reason against that:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83459
--- Comment #3 from Wilco ---
Author: wilco
Date: Thu Feb 8 12:29:28 2018
New Revision: 257481
URL: https://gcc.gnu.org/viewcvs?rev=257481&root=gcc&view=rev
Log:
PR84068, PR83459: Fix sort order of SCHED_PRESSURE_MODEL
The comparison function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
--- Comment #5 from Wilco ---
Author: wilco
Date: Thu Feb 8 12:29:28 2018
New Revision: 257481
URL: https://gcc.gnu.org/viewcvs?rev=257481&root=gcc&view=rev
Log:
PR84068, PR83459: Fix sort order of SCHED_PRESSURE_MODEL
The comparison function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84068
Wilco changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82407
Bug 82407 depends on bug 83459, which changed state.
Bug 83459 Summary: [8 Regression] ICE: qsort checking failed: qsort comparator
non-negative on sorted output: 1 with --param=sched-pressure-algorithm=2
https://gcc.gnu.org/bugzilla/show_bug.cgi
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #4 from Wilco ---
Fixed in r257481.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #5 from
||2019-02-08
Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #7 from Wilco ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00780.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86637
--- Comment #14 from Wilco ---
Author: wilco
Date: Mon Feb 11 18:14:37 2019
New Revision: 268777
URL: https://gcc.gnu.org/viewcvs?rev=268777&root=gcc&view=rev
Log:
[COMMITTED] Fix pthread errors in pr86637-2.c
Fix test errors on targets which d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #8 from Wilco ---
(In reply to Wilco from comment #7)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00780.html
Updated patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00947.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89190
--- Comment #2 from Wilco ---
Author: wilco
Date: Wed Feb 13 16:22:25 2019
New Revision: 268848
URL: https://gcc.gnu.org/viewcvs?rev=268848&root=gcc&view=rev
Log:
[ARM] Fix Thumb-1 ldm (PR89190)
This patch fixes an ICE in the Thumb-1 LDM peepho
||2019-02-15
CC||wilco at gcc dot gnu.org
Summary|ICE in |[8 regression] ICE in
|aarch64_classify_address, |aarch64_classify_address,
|at |at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
Version|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #23 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #25 from Wilco ---
(In reply to Steve Ellcey from comment #24)
> See email strings at:
>
> https://gcc.gnu.org/ml/fortran/2019-01/msg00276.html
> https://gcc.gnu.org/ml/fortran/2019-02/msg00057.html
>
> For more discussion.
Sure, i
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
A recently added optimization uses an inline expansion for sinl (atanl (x)). As
it involves computing sqrtl (x * x + 1) which can overflow for large x, there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86829
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89437
--- Comment #1 from Wilco ---
Author: wilco
Date: Mon Mar 4 12:36:04 2019
New Revision: 269364
URL: https://gcc.gnu.org/viewcvs?rev=269364&root=gcc&view=rev
Log:
Fix PR89437
Fix PR89437. Fix the sinatan-1.c testcase to not run without
a C99 ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89437
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #9 from Wilco ---
Author: wilco
Date: Tue Mar 5 15:04:01 2019
New Revision: 269390
URL: https://gcc.gnu.org/viewcvs?rev=269390&root=gcc&view=rev
Log:
[ARM] Fix PR89222
The GCC optimizer can generate symbols with non-zero offset fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Wilco changed:
What|Removed |Added
Target Milestone|--- |8.5
Summary|[7/8/9 regression] ARM
||2019-03-18
CC||wilco at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Wilco ---
Confirmed. It ICEs in Eigen::internal::gebp_kernel, 2, 4,
false, false>::operator()
It seems to choke on this asm dur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752
--- Comment #3 from Wilco ---
Full instruction:
(insn 531 530 532 19 (parallel [
(set (mem/c:BLK (reg:DI 3842) [29 A0+0 S2 A64])
(asm_operands:BLK ("") ("=rm") 0 [
(mem/c:BLK (reg:DI 3846) [29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752
--- Comment #4 from Wilco ---
Small example which generates the same ICE on every GCC version:
typedef struct { int x, y, z; } X;
void f(void)
{
X A0, A1;
__asm__ ("" : [a0] "+rm" (A0),[a1] "+rm" (A1));
}
So it's completely invalid inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89752
--- Comment #10 from Wilco ---
It seems that rewriting "+rm" into "=rm" and "0" is not equivalent. Eg.
__asm__ ("" : [a0] "=m" (A0) : "0" (A0));
gives a million warnings "matching constraint does not allow a register", so
"0" appears to imply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89493
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #2 from
||wilco at gcc dot gnu.org
Resolution|--- |FIXED
Target Milestone|--- |9.0
--- Comment #9 from Wilco ---
Fixed in GCC9 already, so closing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #11 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #16 from Wilco ---
(In reply to kugan from comment #15)
> (In reply to Wilco from comment #11)
> > There is also something odd with the way the loop iterates, this doesn't
> > look right:
> >
> > whilelo p0.s, x3, x4
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #14 from Wilco ---
(In reply to Jakub Jelinek from comment #13)
> Patches should be pinged after a week if they aren't reviewed, furthermore,
> it is better to CC explicitly relevant maintainers.
I've got about 10 patches waiting, I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81800
--- Comment #16 from Wilco ---
(In reply to Jakub Jelinek from comment #15)
> (In reply to Wilco from comment #14)
> > (In reply to Jakub Jelinek from comment #13)
> > > Patches should be pinged after a week if they aren't reviewed,
> > > furthe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #19 from Wilco ---
(In reply to Peter Bergner from comment #18)
> (In reply to Segher Boessenkool from comment #15)
> > Popping a5(r116,l0) -- assign reg 3
> > Popping a3(r112,l0) -- assign reg 4
> > Popping a2(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #21 from Wilco ---
(In reply to Vladimir Makarov from comment #20)
> (In reply to Wilco from comment #19)
> > (In reply to Peter Bergner from comment #18)
> > > (In reply to Segher Boessenkool from comment #15)
> > > > Popping a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #52 from Wilco ---
(In reply to Jeffrey A. Law from comment #49)
> I think the insv_1 (and it's closely related insv_2) regressions can be
> fixed by a single ior/and pattern in the backend or by hacking up combine a
> bit. I'm still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #54 from Wilco ---
(In reply to Jeffrey A. Law from comment #53)
> Realistically the register allocation issues are not going to get addressed
> this cycle nor are improvements to the overall handling of RMW insns in
> combine. So we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #38 from Wilco ---
(In reply to Segher Boessenkool from comment #37)
> Yes, it is a balancing act. Which option works better?
Well the question really is what is bad about movsi_compare0 that could be
easily fixed?
The move is for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #47 from Wilco ---
(In reply to Segher Boessenkool from comment #46)
> With all three patches together (Peter's, mine, Jakub's), I get a code size
> increase of only 0.047%, much more acceptable. Now looking what that diff
> really *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #52 from Wilco ---
(In reply to Segher Boessenkool from comment #48)
> With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
> That does not fix this PR though :-/
But it does fix most of the codesize regression. Th
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
GCC does not inline fixed-size memmoves. However memmove can be as easily
inlined as memcpy. The existing memcpy infrastructure could be reused/expanded
for this - all loads would be
Assignee: unassigned at gcc dot gnu.org
Reporter: wilco at gcc dot gnu.org
Target Milestone: ---
While GCC now inlines fixed-size mempcpy like memcpy, GCC still emits calls to
mempcpy rather than converting to memcpy. Since most libraries, including
GLIBC, do not have optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90263
--- Comment #2 from Wilco ---
(In reply to Jakub Jelinek from comment #1)
> As stated several times in the past, I strongly disagree.
Why? GCC already does this for bzero and bcopy.
201 - 300 of 724 matches
Mail list logo
