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 way,
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 #100 from Alexander Klepikov
---
Created attachment 55513
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55513&action=edit
Arithmetic right shift late expanding
(In reply to Oleg Endo from comment #99)
> Meanwhile, here's my i
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 #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'
> pa
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. Whe
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 #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 #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 #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 the
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&action=edit
Collapsed libcall and additional loop move invariants patch v3
I digged other targets and I found that c
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 sh.
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 confusing
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 a
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 al
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 sh_loop
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&action=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 e
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 p
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 it
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. sh
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 t
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 probl
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 #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 test_int
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 d
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=49263
--- Comment #48 from Alexander Klepikov
---
I made tests (including *.c files from GCC testsuite) and everything looks fine
for now. But I'm still afraid that pattern for 'ashrsi3_libcall_expand' is too
wide. It is possible to narrow it down as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #45 from Alexander Klepikov
---
>I have an idea. If it's impossible to defer initial optimization,
> maybe it's possible to emit some intermediate insn and catch it and optimize
> later?
Good news. I've made a proof of concept. It
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #43 from Alexander Klepikov
---
> > Thank you! I have an idea. If it's impossible to defer initial optimization,
> > maybe it's possible to emit some intermediate insn and catch it and optimize
> > later?
>
> This is basically what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #41 from Alexander Klepikov
---
> > It looks like with optimization enabled it converts bitwise AND to right
> > shift and then optimizes again. But SH4 has 'shad' and 'shad' can be
> > optimized to 'tst'. And SH2E has libcall instea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #39 from Alexander Klepikov
---
> The tst insn is mainly formed by the combine pass, which relies on certain
> insn patterns and combinations thereof. See also sh.md, around line 530.
I'm sorry, but .md lang is too complicated for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #37 from Alexander Klepikov
---
> Can you also compile for little endian, and most of all, use -O2
> optimization level. Some optimizations are not done below -O2.
Here's source file, I added functions with non-constant shifts
$ c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #35 from Alexander Klepikov
---
(In reply to Oleg Endo from comment #34)
> Bit-tests of char and unsigned char should be covered by the test-suite and
> should work -- at least originally. However, what might be triggering this
> pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #33 from Alexander Klepikov
---
Created attachment 55142
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55142&action=edit
Disable dynamic shift instructions patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #32 from Alexander Klepikov
---
I'm not sure whether I should write here or open new discussion, but these
topics are related very closely. I've been writing a patch to eliminate the
generation of dynamic shift instructions 'shad' an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
Alexander Klepikov changed:
What|Removed |Added
CC||klepikov.alex+bugs at gmail
dot co
41 matches
Mail list logo
