https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #105 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #104)
> I've been thinking about something. I suspect that this patch could take
> work away from other patches. I'm sorry, I don't know how to express myself
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #104 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #103)
> Sorry, I've been busy with other things. I think your patch is OK, but I
> wanted to test it in more detail before committing it.
Oh, it's OK. By the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #103 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #102)
> Created attachment 55543 [details]
> Arithmetic right shift late expanding v2
>
> Here's the patch. I hope I did not miss anything.
>
Sorry, I've been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
Attachment #55503|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #101 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #100)
> Created attachment 55513 [details]
> Arithmetic right shift late expanding
>
> (In reply to Oleg Endo from comment #99)
> > Meanwhile, here's my iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #100 from Alexander Klepikov
---
Created attachment 55513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55513=edit
Arithmetic right shift late expanding
(In reply to Oleg Endo from comment #99)
> Meanwhile, here's my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Oleg Endo changed:
What|Removed |Added
Attachment #28207|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
Attachment #55382|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #97 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #96)
>
> Not really. 'expand_ashiftrt' could emit
>
> mov #imm, r1
> shad r1, r0
>
> and 'mov' instruction would be loop invariant if there's a loop. It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #96 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #95)
> The infinite loop is in splitting of the 'ashrsi3_n_call' pattern with the
> constant 1. This is because 'ashrsi3_n_call' match overlaps with the 'shar'
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #95 from Oleg Endo ---
(In reply to Oleg Endo from comment #93)
> (In reply to Alexander Klepikov from comment #92)
> > I remembered why I used two different insns - first to eliminate infinite
> > loop with help of marking insn with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #94 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #93 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #92)
> I remembered why I used two different insns - first to eliminate infinite
> loop with help of marking insn with attribute, and second because I could
> not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #92 from Alexander Klepikov
---
I remembered why I used two different insns - first to eliminate infinite loop
with help of marking insn with attribute, and second because I could not set
attribute when emitting insn from C code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
Attachment #55367|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #90 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #89)
> Here's what I did
> ...
Can you attach it here as a patch please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #89 from Alexander Klepikov
---
Here's what I did
sh.md:
(define_expand "ashrsi3"
[(parallel [(set (match_operand:SI 0 "arith_reg_dest" "")
(ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #88 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #85)
> > +/* { dg-final { scan-assembler
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #87 from Segher Boessenkool ---
(In reply to Oleg Endo from comment #53)
> (In reply to Segher Boessenkool from comment #52)
> > There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for
> > if
> > you really do not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #86 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #85)
>For now, can you try to run the style check script on your changes?
Thank you, that's what I've been missing!
> > bool
> > expand_ashiftrt (rtx *operands)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #85 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #83)
> Created attachment 55367 [details]
> Collapsed libcall and additional loop move invariants patch v3
Thanks for staying on it! I've looked through the latest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #84 from Alexander Klepikov
---
I've forgot to say that first I ran all tests with SH specific loop
optimization enabled when condition 'optimize && flag_move_loop_invariants' is
true. And only then I ran all tests with final (at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #83 from Alexander Klepikov
---
Created attachment 55367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55367=edit
Collapsed libcall and additional loop move invariants patch v3
I digged other targets and I found that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #82 from Alexander Klepikov
---
I have read the docs and other targets' code, and the puzzle finally came
together. A struct with additional current function context is a really good
idea! I'll implement it in a couple of days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #81 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #78)
> The compiler processes one function at a time, all passes at once. It
> doesn't mix passes of different functions. So I think using global variable
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #80 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #79)
>
> I mean that if a user run GCC with -O1 and we don't do SH specific loop move
> invariants pass at -O1, a user could look at binary (or at .S file) and find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #79 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #78)
> (In reply to Alexander Klepikov from comment #77)
> > > It'd be good if the newly added passes are ran only with -O2 or higher.
> >
> > This can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #78 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #77)
> > It'd be good if the newly added passes are ran only with -O2 or higher.
>
> This can be confusing to users when they discover that not all invariants
> are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #77 from Alexander Klepikov
---
> It'd be good if the newly added passes are ran only with -O2 or higher.
This can be confusing to users when they discover that not all invariants are
moved out of loops. Then we should inform them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #76 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #75)
> I found that patch incorrectly works when '-O0 -fmove-loop-invariants' flags
> are set. Stock loop optimization passes do not run when '-O0' is specified
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #75 from Alexander Klepikov
---
I found that patch incorrectly works when '-O0 -fmove-loop-invariants' flags
are set. Stock loop optimization passes do not run when '-O0' is specified
desipte '-fmove-loop-invariants' is set. I'll do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
Attachment #55284|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #73 from Alexander Klepikov
---
I had to check everything a few more times because I found a bug in my patch
that caused the long shifts to expand incorrectly. I added a test that checks
correct shifts expansion in this regard.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #72 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #71)
>
> > * Do we really need to add that new source file sh_loop.cc with the wrapper
> > classes? Can't we just instantiate the passes that are needed in-place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #71 from Alexander Klepikov
---
> There are some formatting nits in your patch, please check again:
Thanks for pointing that out, I'll check again.
> But more interestingly:
> * Do we really need to add that new source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #70 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #69)
> Created attachment 55284 [details]
> Collapsed libcall and additional loop move invariants patch
Thanks for sharing the patch. I also don't have the GCC SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #69 from Alexander Klepikov
---
Created attachment 55284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55284=edit
Collapsed libcall and additional loop move invariants patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #68 from Alexander Klepikov
---
OK, I finished my patch. Let me remind you briefly, what it does.
First, it does not emit library call for ashrsi3 during expand pass. Instead it
emits intermediate 'collapsed' libcall insn which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #67 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #66)
> (In reply to Alexander Klepikov from comment #65)
> > > I'm thinking of something else.
> >
> > During kernel compile I got few internal errors in different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #66 from Alexander Klepikov
---
(In reply to Alexander Klepikov from comment #65)
> > I'm thinking of something else.
>
> During kernel compile I got few internal errors in different passes. That
> is, additional loop optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #65 from Alexander Klepikov
---
> I'm thinking of something else.
During kernel compile I got few internal errors in different passes. That is,
additional loop optimization pass patch is no good at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #64 from Alexander Klepikov
---
> We have to consider that SH is also a linux target and it's also used to
> build larger applications (and GCC itself ...). It'd be good to not regress
> too much in this regard. One way to check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #63 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #62)
>
> My project is small and it compiles in under 1 second on both clean and
> patched GCC. sh.exp test suite mean run time is 117s on clean and 119s on
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #62 from Alexander Klepikov
---
> I'm a bit concerned about the increased compile time. Have you observed
> anything (negative) in this regard?
My project is small and it compiles in under 1 second on both clean and patched
GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #61 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #60)
> > Maybe it's easier to add some shift specific passes.
>
> Well, I couldn't think of anything better and ported the loop optimization
> pass. More precisely,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #60 from Alexander Klepikov
---
> Maybe it's easier to add some shift specific passes.
Well, I couldn't think of anything better and ported the loop optimization
pass. More precisely, all loop optimization passes, because they are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #59 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #58)
>
> Ouch. That's a real problem. Short loops can become slower on about 10%. But
> is it possible to detect a loop during expand pass? It looks like basic
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #58 from Alexander Klepikov
---
> Another thing ... the reason why it's desirable to expand into the libcall
> earlier is to allow hoisting the function call address outside of loops and
> things like that.
Ouch. That's a real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #57 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #56)
>
> > In that test you can see the unnecessary push/pop of PR. This is because
> > initially it wanted to expand as a library call, but then your patterns
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #56 from Alexander Klepikov
---
> > Regarding testsuite. There's execute fails, but this is due to lack of
> > multilib. I'll rebuild and retest.
> >
> > There's also fail in pr64345-1.c, in this function:
> > [...]
> >
> > But it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #55 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #54)
> Regarding testsuite. There's execute fails, but this is due to lack of
> multilib. I'll rebuild and retest.
>
> There's also fail in pr64345-1.c, in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #54 from Alexander Klepikov
---
Regarding testsuite. There's execute fails, but this is due to lack of
multilib. I'll rebuild and retest.
There's also fail in pr64345-1.c, in this function:
typedef signed char int8_t;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #53 from Oleg Endo ---
(In reply to Segher Boessenkool from comment #52)
>
> There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for if
> you really do not want the instruction combiner to create particular
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #52 from Segher Boessenkool ---
(In reply to Alexander Klepikov from comment #50)
> But maybe there is a way to exclude particular insn from combine pass? (I
> guess not).
In general, it is best to let combine just work on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #51 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #50)
>
> Ooh, my bad! You are absolutely right. A function is inlined and division is
> converted to 4 'shar's which at combine pass are catched by 'define_insn
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #50 from Alexander Klepikov
---
> > I've found that my patch catches integer division. In short, it appears to
> > work unpredictable. It looks like there's no easy way to catch right shift.
>
> What do you mean it catches integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #49 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #48)
> Let's continue discussion we started here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
>
> I've found that my patch catches integer division. In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Alexander Klepikov changed:
What|Removed |Added
CC||klepikov.alex+bugs at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #47 from Oleg Endo ---
Thanks for the reminder. The issue hasn't been fully resolved. Please leave
this PR open. This will be helpful when getting back to the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #45 from Oleg Endo ---
Author: olegendo
Date: Fri May 6 09:41:57 2016
New Revision: 235950
URL: https://gcc.gnu.org/viewcvs?rev=235950=gcc=rev
Log:
gcc/
PR target/54089
* config/sh/sh.md (*rotcr): Add another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #44 from Oleg Endo ---
Author: olegendo
Date: Mon Feb 22 13:33:31 2016
New Revision: 233601
URL: https://gcc.gnu.org/viewcvs?rev=233601=gcc=rev
Log:
gcc/
PR target/69806
PR target/54089
* config/sh/sh.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Segher Boessenkool segher at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #40 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Rich Felker from comment #39)
Oleg, do you have rights under your copyright assignment agreement to
dual-license the libgcc part of the patch under GPLv2 so it could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #42 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #41)
On the other hand, there are quite a few archs (more modern ones
mostly) where the Linux kernel uses the real libgcc.
If this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #43 from Segher Boessenkool segher at gcc dot gnu.org ---
The archs that already use the real libgcc are arc, cris, hexagon,
m32r, nios2, openrisc, parisc, xtensa.
grep -w LIBGCC ~/src/kernel/arch/*/Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #39 from Rich Felker bugdal at aerifal dot cx ---
Oleg, do you have rights under your copyright assignment agreement to
dual-license the libgcc part of the patch under GPLv2 so it could be included
in the kernel, and if so, would you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Rich Felker bugdal at aerifal dot cx changed:
What|Removed |Added
CC||bugdal at aerifal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #34 from Oleg Endo olegendo at gcc dot gnu.org ---
Thanks for spotting and pin pointing. Do you have a bit more info, maybe a
reduced test case?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #35 from Rich Felker bugdal at aerifal dot cx ---
No, but the cause is simple -- the kernel doesn't use libgcc but defines its
own versions of these functions, and has the old ones but not the new ones. I
tried just removing the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #36 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Rich Felker from comment #35)
No, but the cause is simple -- the kernel doesn't use libgcc but defines its
own versions of these functions, and has the old ones but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #37 from Rich Felker bugdal at aerifal dot cx ---
I expect this is going to be problematic from a license perspective unless they
can be licensed under GPLv2...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #38 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Rich Felker from comment #33)
The commit in comment 16 broke Linux (the kernel) and nobody seems to have
noticed since 2012...
There aren't that many (publicly known)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #32 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Tue Dec 16 21:37:42 2014
New Revision: 218795
URL: https://gcc.gnu.org/viewcvs?rev=218795root=gccview=rev
Log:
gcc/testsuite/
PR target/54089
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #31 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Fri May 16 23:12:19 2014
New Revision: 210537
URL: http://gcc.gnu.org/viewcvs?rev=210537root=gccview=rev
Log:
gcc/
PR target/54089
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #30 from Oleg Endo olegendo at gcc dot gnu.org ---
A case from libmpeg2/slice.c:
mov.b @(1,r10),r0// load of shift amount
shldr7,r6
add #1,r6
extu.b r0,r0 // zero extend shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #29 from Oleg Endo olegendo at gcc dot gnu.org 2013-02-16
11:36:37 UTC ---
Another case taken from CSiBE / bzip2, where reusing the intermediate shift
result would be better:
void uInt64_from_UInt32s ( UInt64* n, UInt32 lo32,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #28 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-13
01:13:55 UTC ---
(In reply to comment #27)
FWIW, while the ARC600/700 have a full set up static and dynamic shifts,
the ARC 601 with the swap option has similar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #26 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-09
10:48:17 UTC ---
(In reply to comment #25)
Maybe the better solution would indeed be to add a
arith - logical shift conversion pass before combine, or try to convert
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #27 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org
2012-11-09 13:29:10 UTC ---
(In reply to comment #26)
(In reply to comment #25)
Maybe the better solution would indeed be to add a
arith - logical shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #25 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-07
23:31:20 UTC ---
Created attachment 28633
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28633
Arithmetic right shift rework 2
This could be an alternative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #24 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-06
11:55:47 UTC ---
Author: olegendo
Date: Tue Nov 6 11:55:43 2012
New Revision: 193236
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=193236
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #23 from Oleg Endo olegendo at gcc dot gnu.org 2012-10-16
11:49:14 UTC ---
(In reply to comment #22)
(In reply to comment #0)
The code related to shift patterns in sh.c / sh.md maybe could use some
improvements here and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #21 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-30
18:45:56 UTC ---
I've noticed that there seems to be a problem with register allocation related
to shift insns. For example in the CSiBE set, I've seen sequences such as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #20 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-25
19:06:34 UTC ---
Author: olegendo
Date: Tue Sep 25 19:06:28 2012
New Revision: 191743
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191743
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #19 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-19
17:48:31 UTC ---
Author: olegendo
Date: Wed Sep 19 17:48:25 2012
New Revision: 191490
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191490
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #18 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-17
23:29:52 UTC ---
Created attachment 28207
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28207
Arithmetic right shift rework
I have tried to apply the same strategies to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #16 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-10
20:35:30 UTC ---
Author: olegendo
Date: Mon Sep 10 20:35:25 2012
New Revision: 191161
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=191161
Log:
PR target/54089
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #17 from Oleg Endo olegendo at gcc dot gnu.org 2012-09-10
21:27:30 UTC ---
Created attachment 28163
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28163
Alternative dropped software dynamic ashlsi3,lshrsi3 patch
(In reply to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #15 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-22
22:52:25 UTC ---
Author: olegendo
Date: Wed Aug 22 22:52:17 2012
New Revision: 190603
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190603
Log:
PR target/54089
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-20
21:29:26 UTC ---
For the record, I've committed the following under the wrong PR number by
accident.
Author: olegendo
Date: Mon Aug 20 20:54:20 2012
New Revision: 190545
URL:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-16
23:13:18 UTC ---
Author: olegendo
Date: Thu Aug 16 23:13:11 2012
New Revision: 190457
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190457
Log:
PR target/54089
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #12 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-11
20:25:45 UTC ---
(In reply to comment #9)
(In reply to comment #8)
#define SH_DYNAMIC_SHIFT_COST (TARGET_DYNSHIFT ? 1 : 20)
Sounds reasonable. Perhaps some historical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #10 from Ryan Mansfield rmansfield at qnx dot com 2012-08-10
14:24:55 UTC ---
Created attachment 27985
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27985
preprocessed src
./xgcc -B. -w ~/ice2.i -c -Os
/home/ryan/ice2.i: In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-10
15:40:07 UTC ---
(In reply to comment #10)
Created attachment 27985 [details]
preprocessed src
./xgcc -B. -w ~/ice2.i -c -Os
/home/ryan/ice2.i: In function 'tg_extent':
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
CC||kkojima at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:17:54
UTC ---
OK, I checking out the preprocessed file reveals the following relevant pieces:
typedef struct page {
struct list_head list;
struct address_space *mapping;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:27:55
UTC ---
Author: olegendo
Date: Thu Aug 9 23:27:51 2012
New Revision: 190273
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190273
Log:
PR target/54089
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-09 23:36:10
UTC ---
Kaz, another thing I'm a bit unsure about ...
#define SH_DYNAMIC_SHIFT_COST \
(TARGET_HARD_SH4 ? 1 : TARGET_DYNSHIFT ? (optimize_size ? 1 : 2) : 20)
Do you
1 - 100 of 106 matches
Mail list logo
