https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Target||powerpc*-*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89310
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89193
--- Comment #3 from Segher Boessenkool ---
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
--- Comment #7 from Segher Boessenkool ---
truncate:SI of ashift:DI looks wrong already; I'd expect ashift:SI of a subreg?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87761
--- Comment #9 from Segher Boessenkool ---
It looks more like the kind of thing that combine make_extraction,
make_compound_operation, expand_compound_operation comes up with.
This is not a new problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #2 from Segher Boessenkool ---
Thanks for the analysis!
(In reply to Vladimir Makarov from comment #1)
> The very first ira-costs pass runs in sched1 and it generates the following
> costs
> r125 costs: BASE_REGS:1 GENERAL_REGS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 14 18:46:18 2019
New Revision: 26
URL: https://gcc.gnu.org/viewcvs?rev=26&root=gcc&view=rev
Log:
Backport from trunk
2018-07-26 Segher Boessenkool
||segher at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Segher Boessenkool ---
This doesn't backport to 8. Closing as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #16 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 14 18:57:54 2019
New Revision: 268889
URL: https://gcc.gnu.org/viewcvs?rev=268889&root=gcc&view=rev
Log:
Backport from trunk
2019-01-18 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86684
--- Comment #15 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 14 19:03:54 2019
New Revision: 268890
URL: https://gcc.gnu.org/viewcvs?rev=268890&root=gcc&view=rev
Log:
Backport from trunk
2018-08-31 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #13 from Segher Boessenkool ---
Author: segher
Date: Thu Feb 14 19:03:54 2019
New Revision: 268890
URL: https://gcc.gnu.org/viewcvs?rev=268890&root=gcc&view=rev
Log:
Backport from trunk
2018-08-31 Segher Boessenkool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85805
--- Comment #14 from Segher Boessenkool ---
I backported it anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #6 from Segher Boessenkool ---
Created attachment 45767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45767&action=edit
reg_move_cost patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #7 from Segher Boessenkool ---
Created attachment 45768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45768&action=edit
NON_SPECIAL_REGS removal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #8 from Segher Boessenkool ---
I currently have the two previous patches in my stack, and I see no
regressions (on powerpc64-linux -m32/-m64).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #9 from Segher Boessenkool ---
Erm. No new ICEs, I mean. Various tests expect different generated code
then you get with that. Some of it is an improvement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88347
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Segher Boessenkool changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80505
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89308
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |SUSPENDED
--- Comment #9 from Seghe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #8 from Segher Boessenkool ---
The C standard does not allow the line number (in a #line directive) to be
smaller than 1 or bigger than 0x7fff. It says nothing about actually
having this many lines, or overflowing the line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #11 from Segher Boessenkool ---
(In reply to Jonny Grant from comment #9)
> Maybe zero could be disallowed too.
Yes, but maybe we need that for historical reasons.
> Not sure what is best here, I'm not knowledgeable of GCC, but mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
--- Comment #11 from Segher Boessenkool ---
If you use -fsignaling-nans everything works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86367
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89443
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55681
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #14 from Segher Boessenkool ---
Cool results so far!
+FAIL: gcc.target/powerpc/p9-dimode1.c scan-assembler-not \\mmtvsrd\\M
p9_plus_1:
.LFB1:
.cfi_startproc
- vspltisw 0,1
- vupklsw 0,0
+ li 9,1
+ mt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #20 from Segher Boessenkool ---
Maybe you want to say .-1 instead of -1 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585
--- Comment #10 from Segher Boessenkool ---
1) It wasn't defined behaviour before, so nothing changed in that regard.
Many changes changes behaviour on invalid code. Not all invalid code gets
a diagnostic.
2) Incompatible clang behaviour on GNU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585
--- Comment #15 from Segher Boessenkool ---
(In reply to Rolf Eike Beer from comment #14)
> The other thing is: given that 8.3 does not show a diagnostic message that
> is at least remotely helpful this looks for any end user just like a
> compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89585
--- Comment #17 from Segher Boessenkool ---
Hello Harald,
Yes, that is what I would like you guys to do. But I'll stop working
on this now, that is fine as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89626
--- Comment #4 from Segher Boessenkool ---
If you use -mcpu=power8 (or up) it works fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89626
--- Comment #6 from Segher Boessenkool ---
"vector signed __int128" and "vector unsigned __int128" are both defined,
and both work fine. But "vector __int128" is not defined in the ABI, and
does not work unless you are building for power8 or up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89626
--- Comment #10 from Segher Boessenkool ---
But it behaves exactly likes this on LE ELFv2 systems as well.
Only explicitly signed and unsigned types are documented, sure, but that
does not make all that much sense, IMO.
||2019-03-07
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #11 from Segher Boessenkool ---
I'll take this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82704
--- Comment #3 from Segher Boessenkool ---
Author: segher
Date: Sun Mar 10 12:49:13 2019
New Revision: 269553
URL: https://gcc.gnu.org/viewcvs?rev=269553&root=gcc&view=rev
Log:
2019-03-10 Tommy Nguyen
PR contrib/82704
* downl
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
With a compiler bootstrapped with --with-cpu=power7 I get
spawn -ignore SIGHUP /home/segher/build/tot/gcc/testsuite/g++13/../../xg++
-B/ho
me/segher/build/tot/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89715
--- Comment #2 from Segher Boessenkool ---
Yeah it looks like that a lot, thanks. Let's wait with marking it as
dup until we know for sure though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89715
Segher Boessenkool changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Segher Boes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #2 from Segher Boessenkool ---
Author: segher
Date: Fri Mar 15 22:09:15 2019
New Revision: 269716
URL: https://gcc.gnu.org/viewcvs?rev=269716&root=gcc&view=rev
Log:
LRA: side_effects_p stmts' output is not invariant (PR89721)
PR8972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89721
--- Comment #3 from Segher Boessenkool ---
Fixed on trunk so far.
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: segher at gcc dot gnu.org
Target Milestone: ---
Hi Kelvin,
The test does not only run on VSX on purpose:
/* This test should run the same on any target that supports altivec/dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736
Segher Boessenkool changed:
What|Removed |Added
Target||powerpc*-*-*
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
--- Comment #2 from Segher Boessenkool ---
(This is on a PowerPC 750).
The compiler makes an unaligned store for this, because it knows no better
than it is just a SImode store:
d_5 = (int) f_4(D);
_10 = (unsigned int) d_5;
MEM[(short int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
--- Comment #5 from Segher Boessenkool ---
Yes, it is just a code quality issue.
I have the attached patch, and it works; it needs to be updated so that the
alignment check is only done for CPUs where it is needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89736
--- Comment #2 from Segher Boessenkool ---
I found this on a Power7 (maybe -m32, not sure).
Your patch is eerily like what I did to fix this in testing, but the comment
right below says it does not use -mvsx on purpose?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89746
--- Comment #7 from Segher Boessenkool ---
Author: segher
Date: Tue Mar 19 16:58:42 2019
New Revision: 269802
URL: https://gcc.gnu.org/viewcvs?rev=269802&root=gcc&view=rev
Log:
rs6000: Unaligned stfiwx on older CPUs (PR89746)
The "classic" Powe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88055
Segher Boessenkool changed:
What|Removed |Added
Priority|P2 |P1
--- Comment #8 from Segher Boess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #28 from Segher Boessenkool ---
Patches should go to gcc-patches@. That is where reviews happen, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89776
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc-*-*-* |powerpc*-*-*
Status|UNC
||segher at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #3 from Segher Boessenkool ---
The internals manual explains this:
Note that @code{match_dup} should not be used to tell the compiler that
a particular register is being used for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #31 from Segher Boessenkool ---
If an asm makes a function non-pure, that asm should be volatile in the
first place? Or are there any cases where that is not true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #32 from Segher Boessenkool ---
Historically, a local register asm variable *does* live in that variable
for its entire scope. This stopped working correctly, even with the many
caveats there were for it, and many years ago the manua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
--- Comment #34 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #33)
> On Sat, 30 Mar 2019, segher at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87984
> >
> > ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #15 from Segher Boessenkool ---
It seems to be that this happens for huge basic blocks, and the combiner
tries to combine pairs of instructions that are far apart. This is unlikely
to work often, and the cost is quadratic in # insns,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928
--- Comment #6 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #5)
> I didn't have any better ideas, so fixed via comment #2.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #17 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #16)
> I would guess so. I wonder if the combiner could restrict itself
> here? Maybe LUID "distances" are an approximation? Doesn't the
> combiner use DF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #40 from Segher Boessenkool ---
You'll get much better results if you don't use insv in your machine
description; writing it with the input and output separate (and then
using a "0" constraint) is much friendlier to the optimisers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #41 from Segher Boessenkool ---
Seeing that the code in your examples can be expressed as a bitfield insert
requires that combine sees that only the low 8 bits of reg 93 can be non-zero,
by the way. It usually does not know this. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960
--- Comment #19 from Segher Boessenkool ---
(In reply to rguent...@suse.de from comment #18)
> Hmm, so if we'd have numbered stmts in an EBB we could check the
> distance between set and use and not combine when that gets too big?
Yeah. Or we c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #11 from Segher Boessenkool ---
(In reply to Wilco from comment #8)
> push{r4, lr}
> mov r4, r0
> cmp r4, #0
Why does it copy r0 to r4 and then compare r4? On more modern machines it
is faster to compar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #12 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #11)
> (In reply to Wilco from comment #8)
> > mov r4, r0
> > cmp r4, #0
>
> Why does it copy r0 to r4 and then compare r4? On more modern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #42 from Segher Boessenkool ---
The "movk" failures... This is from insv_1.c:
Trying 7, 6 -> 8:
7: r95:DI=0x1d6b
6: r93:DI=r97:DI&0x
REG_DEAD r97:DI
8: r94:DI=r93:DI|r95:DI
REG_DEAD r9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #44 from Segher Boessenkool ---
(In reply to Jeffrey A. Law from comment #43)
> The problem with your suggestions Segher is that we'd have to do them for
> every target which defines insns with a zero_extract destination and that's
>
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #7 from Segher Boessenkool ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007
--- Comment #7 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #3)
> Why does sel-sched try to propagate hard registers into insns before RA?
> The whole point of the combiner changes was not to do that, so that the RA
> can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369
Segher Boessenkool changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pthaugen at linux dot
ibm.co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #20 from Segher Boessenkool ---
I currently get (on BE; the testcase forces -mcpu=power8):
std 3,-16(1)
addi 9,1,-12
lxsiwzx 32,0,9
#APP
# 10 "vsx-simode2.c" 1
xxlor 32,32,32 # v, v constraints
# 0
|unassigned at gcc dot gnu.org |segher at gcc dot
gnu.org
--- Comment #9 from Segher Boessenkool ---
I have a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #15 from Segher Boessenkool ---
Forming thread by copy 0:a0r111-a4r117 (freq=500):
Result (freq=3500): a0r111(2500) a4r117(1000)
Forming thread by copy 2:a3r112-a5r116 (freq=125):
Result (freq=4500): a3r112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #16 from Segher Boessenkool ---
(Which would make insn 50 go away, if you prefer to look at it that way).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #23 from Segher Boessenkool ---
It says (I added some debug)
Insn 50(l0): point = 27
ignoring for conflicts:
(reg:SI 0 r0 [ a ])
but non_conflicting_reg_copy_p isn't called at all where it is improving
the allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-gnu-linux, |powerpc*-*-*
|pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89794
--- Comment #8 from Segher Boessenkool ---
Author: segher
Date: Mon Apr 15 11:33:29 2019
New Revision: 270368
URL: https://gcc.gnu.org/viewcvs?rev=270368&root=gcc&view=rev
Log:
combine: Count auto_inc properly (PR89794)
The code that checks if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90070
--- Comment #6 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #5)
> Oh that is PR 22326
Indeed it is. And your conclusion there ("we need some pass that does
this properly", instead of the current thing during expand)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
Segher Boessenkool changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
--- Comment #4 from Segher Boessenkool ---
(Yup, worked).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #27 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #26)
> ;; a4(r117,l0) conflicts: a3(r112,l0)
> ;; total conflict hard regs:
> ;; conflict hard regs:
>
> ;; a5(r116,l0) conflicts: cp0:a0(r111)<->a4(r11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17108
--- Comment #9 from Segher Boessenkool ---
Author: segher
Date: Wed Apr 17 09:45:57 2019
New Revision: 270407
URL: https://gcc.gnu.org/viewcvs?rev=270407&root=gcc&view=rev
Log:
rs6000: Improve the load/store-with-update patterns (PR17108)
Many
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #31 from Segher Boessenkool ---
It's how you do a parallel of a mov and a flags set, which of course you
can have before RA, and you want created by combine, typically. Or do I
misunderstand the question?
(I though Arm have a "movs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89410
--- Comment #22 from Segher Boessenkool ---
#line 0 isn't valid C code. If it causes problems we should just
error on it (and perhaps even when it doesn't (yet) cause problems).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #35 from Segher Boessenkool ---
Peter's patch solves this particular problem, but not the PR unfortunately.
I finally understand Jakub's comment 30. This patch solves the PR (also
without Peter's patch):
===
diff --git a/gcc/config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #37 from Segher Boessenkool ---
Yes, it is a balancing act. Which option works better?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #39 from Segher Boessenkool ---
On a linux kernel defconfig build it increases code size by 0.567%.
That seems a bit much :-(
The peephole only recognises
mov rA,rB
cmp rB,#0
and not
mov rA,rB
cmp rA,#0
or
cmp rB,#0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #41 from Segher Boessenkool ---
(In reply to Wilco from comment #38)
> Well the question really is what is bad about movsi_compare0 that could be
> easily fixed?
"Easily fixed"... There is no such thing here.
Because it is a parall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #42 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #40)
> The question is what the code size differences would be with those changes
> (i.e. how often does it help not to have *movsi_compare0 make RA decisions
> w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16798
--- Comment #9 from Segher Boessenkool ---
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 *is* :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #46 from Segher Boessenkool ---
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 *is* :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #48 from Segher Boessenkool ---
With just Peter's and Jakub's patch, it *improves* code size by 0.090%.
That does not fix this PR though :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #49 from Segher Boessenkool ---
(In reply to Wilco from comment #47)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #50 from Segher Boessenkool ---
The insn is
(insn 7 3 8 2 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 0 r0 [116])
(const_int 0 [0])))
(set (reg/v:SI 4 r4 [orig:112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #53 from Segher Boessenkool ---
(In reply to Richard Earnshaw from comment #51)
> In the more general case splitting this would produce worse code, not
> better, since then we'd end up with two instructions rather than one.
Sure, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #54 from Segher Boessenkool ---
(In reply to Wilco from comment #52)
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405
Segher Boessenkool changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #13 from Segher Boes
801 - 900 of 3228 matches
Mail list logo
