https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #20 from Segher Boessenkool ---
(In reply to Wilco from comment #19)
> Well insn_cost() uses COSTS_N_INSNS (1) for instructions with unknown (zero)
> costs. That's a reasonable default and gives more accurate cost comparisons,
> eg. 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #19 from Wilco ---
(In reply to Segher Boessenkool from comment #16)
> (In reply to Wilco from comment #14)
> > Note there is also an issue with costs, if the cost is zero then it seems to
> > behave like infinite cost.
>
> 0 means u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #17 from Segher Boessenkool ---
Please do the combine dumps with details enabled; these are pretty useless.
(-fdump-rtl-combine-all)
A C testcase would be very helpful, too (or some magic configure command
to run on some cfarm machin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #16 from Segher Boessenkool ---
(In reply to Wilco from comment #14)
> Note there is also an issue with costs, if the cost is zero then it seems to
> behave like infinite cost.
0 means unknown cost. Any known cost is treated as at l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #15 from Segher Boessenkool ---
(In reply to Wilco from comment #13)
> It seems the safest way
> to split an instruction is to place the new instructions next to each other.
combine can only place new insns at i2 and i3, in either or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #14 from Wilco ---
Note there is also an issue with costs, if the cost is zero then it seems to
behave like infinite cost. It would be better to properly cost an instruction
sequence given there is a new interface for this now. If the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
Wilco changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #12 from nsz at gcc dot gnu.org ---
the wrong string seems to be caused by a missing ldm
good main:
...
mov r4, #0
str r4, [sp, #32]
mov r2, #2
str r2, [sp, #36]
add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #11 from nsz at gcc dot gnu.org ---
Created attachment 44562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44562&action=edit
bad rtl dump of combine pass
attached good and bad dump of combine, i also tried to look at the array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
nsz at gcc dot gnu.org changed:
What|Removed |Added
CC||nsz at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #9 from Andrey Guskov ---
OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #8 from Segher Boessenkool ---
So is it worse code, better code, is the testcase broken / suboptimal?
The haswell problem seems to be completely unrelated, so open a separate PR
please.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
Andrey Guskov changed:
What|Removed |Added
CC||andrey.y.guskov at intel dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #6 from Segher Boessenkool ---
So, what is happening at all? What is different during/after combine, etc.?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #5 from Christophe Lyon ---
I think in the "ok" version we have:
add ip, sp, #60
...
ldm ip, {r0, r1}
...
add r2, sp, #72
ldm r2, {r0, r1}
in the "ko" version we have:
ldr r1, [sp, #64]
...
ldr r1, [sp, #76]
So in the "ko" version w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #4 from Christophe Lyon ---
Created attachment 44488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44488&action=edit
Good code
This is with r263197 and r263067 (your patch) reverted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #3 from Christophe Lyon ---
Created attachment 44487
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44487&action=edit
Wrong code generated
This is with trunk @r263197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #2 from Christophe Lyon ---
gfortran.log contains:
STOP 4
STOP 4
STOP 4
before the execution fails
I'll regenerate the 2 asm files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
--- Comment #1 from Segher Boessenkool ---
Could you trace this down to some bad code generated, at least?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
21 matches
Mail list logo
