https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #19 from Arnd Bergmann ---
I've confirmed that the current gcc trunk addresses the original problem in the
Linux kernel build, aside from the reduced test case. Thanks a lot for working
on this!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #17 from Jeffrey A. Law ---
Author: law
Date: Tue Mar 22 21:32:34 2016
New Revision: 234409
URL: https://gcc.gnu.org/viewcvs?rev=234409&root=gcc&view=rev
Log:
PR target/70232
tree-ssa-threadbackward.c
(fsm_fin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #16 from Jeffrey A. Law ---
So for thread paths noted in c#15 we have the following pieces of data
1. 69 statements to copy
2. 7 blocks to copy
3. Threads through latch, but does not create an irreducible loop
4. Eliminates a simp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #15 from Jeffrey A. Law ---
So this is definitely related to the FSM threader not being able to share a
single jump threading path. Here's an example:
j.c.110t.dom2: Registering FSM jump thread: (23, 25) incoming edge; (25, 28)
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #14 from Jeffrey A. Law ---
WRT c#8, the FSM threader is much better at finding jump threading
opportunities which involve multiple blocks in the thread path. I'm still not
entirely happy with the heuristics around that.
Closely rel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #12 from Arnd Bergmann ---
Created attachment 37991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37991&action=edit
simpler test case without manual byte swap
For reference, I have sent a patch to the kernel to replace the ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #6 from Richard Biener ---
Btw, the bswap pass for arm doesn't detect any bswap32 or bswap64 instruction.
There is
(define_expand "bswapsi2"
[(set (match_operand:SI 0 "s_register_operand" "=r")
(bswap:SI (match_operand:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #10 from Richard Biener ---
(In reply to Thomas Preud'homme from comment #9)
> (In reply to Richard Biener from comment #7)
> > The bswap pass could learn to split this up into two loads and bswaps and
> > combine the results with a s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Richard Biener changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #8 from Richard Biener ---
But not sure how this became a regression - does GCC 5 really do better here?
With -fno-tree-dominator-opts the warning no longer triggers and we get
sub sp, sp, #428
so it may be another jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #11 from Arnd Bergmann ---
For reference, I have sent a patch to the kernel to replace the open-coded
byteswap with a __builtin_bswap64. This produces much better object code with
both gcc-5 and gcc-6 than the original version, so it'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Ramana Radhakrishnan changed:
What|Removed |Added
CC||law at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #9 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #7)
> The bswap pass could learn to split this up into two loads and bswaps and
> combine the results with a single shift and or.
I'll add it to the bswap TODO l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
--- Comment #4 from Arnd Bergmann ---
I've tried out a few more things as well, to see if the alignment of the struct
lpfc_name type or the builtin memcpy makes a different. Replacing the array of
eight bytes with a single uint64_t and scalar ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70232
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
19 matches
Mail list logo
