https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|9.3 |9.4
--- Comment #24 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #23 from Andreas Schwab ---
gcc.target/aarch64/pr93565.c fails with -mabi=ilp32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #22 from Segher Boessenkool ---
T0T2T3T4
alpha 6049096 100.020% 100.018% 100.001%
arc 4019384 100.000% 99.989% 99.989%
arm 14177962 99.999% 99.999%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #21 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Segher Boessenkool from comment #18)
> > Created attachment 47841 [details]
> > Patch to treat sign_extend as is_just_move
>
> Do you think z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #20 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #18)
> Created attachment 47841 [details]
> Patch to treat sign_extend as is_just_move
Do you think zero_extend should maybe be treated as such too? What about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #19 from Segher Boessenkool ---
With that above patch, I get (T0 is original, T2 is with patch, these are
file sizes of a Linux build, mostly defconfig):
T0T2
alpha 6049096 100.020%
arc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #18 from Segher Boessenkool ---
Created attachment 47841
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47841&action=edit
Patch to treat sign_extend as is_just_move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #17 from Segher Boessenkool ---
That above commit is just a spec special, it doesn't solve anything else,
imnsho.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #16 from Segher Boessenkool ---
It is not the same cost. It reduces the path length.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #15 from CVS Commits ---
The master branch has been updated by Wilco Dijkstra :
https://gcc.gnu.org/g:5bfc8303ffe2d86e938d45f13cd99a39469dac4f
commit r10-6598-g5bfc8303ffe2d86e938d45f13cd99a39469dac4f
Author: Wilco Dijkstra
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #14 from Richard Earnshaw ---
With the simpler test case we see
Breakpoint 1, try_combine (i3=0x764d33c0, i2=0x764d3380, i1=0x0,
i0=0x0, new_direct_jump_p=0x7fffd850,
last_combined_insn=0x764d33c0)
at /h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #13 from Segher Boessenkool ---
nonzero_bits is not reliable. We also cannot really do what you propose
here, all of this is done for *every* combination.
We currently generate
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #12 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #11)
> (The original problem I have an idea for -- don't generate a parallel of
> two SETs with equal SET_SRC -- but that doesn't handle the new case).
For the n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #11 from Segher Boessenkool ---
(The original problem I have an idea for -- don't generate a parallel of
two SETs with equal SET_SRC -- but that doesn't handle the new case).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
--- Comment #10 from Segher Boessenkool ---
One of the first things combine tries is
Trying 7 -> 8:
7: r96:SI=r104:SI&0xe
REG_DEAD r104:SI
8: r99:DI=sign_extend(r96:SI)
...
Successfully matched this instruction:
(set (reg/v:SI 96 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565
Wilco changed:
What|Removed |Added
CC||segher at kernel dot
crashing.org
Su
18 matches
Mail list logo