https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97431
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97431
--- Comment #6 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #5)
So the difference seems to be only the -fPIC option? Can you get the
preprocessed .i file with -save-temps ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #4 from Oleg Endo ---
(In reply to Rin Okuyama from comment #3)
> Thank you very much for your analysis!
>
> If that peephole is removed, GCC 10.3 generates working codes.
>
> NetBSD/shle built by this compiler works fine as far as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111898
Oleg Endo changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101737
Oleg Endo changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
Oleg Endo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113533
--- Comment #17 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #16)
> Note that Jakub recently twiddled fwprop to throttle it back a little. As a
> result the regressions seen in this BZ are no longer an issue. I'm going to
> remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111343
Oleg Endo changed:
What|Removed |Added
Target|SH4 |sh*-*-*
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058
--- Comment #12 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #11)
> The patch looks to do basically the right thing and given Richard knows his
> code better than I, let's go with it.
>
> I'll respin sh4* once it lands upstream t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058
--- Comment #15 from Oleg Endo ---
(In reply to Andrew Pinski from comment #14)
> Yes I have not submitted this yet because I have been busy with some other
> patches. But I should have some time on Friday to work on getting this patch
> tested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116189
--- Comment #12 from Oleg Endo ---
(In reply to Andrew Pinski from comment #8)
> ```
> (gdb) condition 1 x_rtl.emit.x_cur_insn_uid==1083
>
> #0 make_insn_raw (pattern=0x77570858) at ../../gcc/emit-rtl.cc:4137
> #1 0x01f10469 in sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #137 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #136)
> Hope these observations help for clarifying issues.
Kaz, thanks so much for chiming in and looking at these after such a long time!
It's really appreciated!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65317
--- Comment #6 from Oleg Endo ---
If larger constants are formed during 1st combine (note -- we now have a 2nd
late combine pass after register allocation), they could be at least be hoisted
out of loops. See also the latest patch
https://gcc.gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089
--- Comment #106 from Oleg Endo ---
(In reply to Oleg Endo from comment #103)
> (In reply to Alexander Klepikov from comment #102)
> > Created attachment 55543 [details]
> > Arithmetic right shift late expanding v2
> >
> > Here's the patch. I ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #139 from Oleg Endo ---
Created attachment 58859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58859&action=edit
testcase for attachment 58836 with -mno-lra
(In reply to Kazumoto Kojima from comment #135)
> Created attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #140 from Oleg Endo ---
Created attachment 58860
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58860&action=edit
testcase for attachment 58831, 58832, 58833, 58836
The attached test case, when compiled with 'sh-elf-gcc -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #162 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #153)
> Created attachment 58886 [details]
> a revised patch for c#135 and c#139
>
> (In reply to Oleg Endo from comment #139)
>
> If we try to keep the old behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #163 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #130)
> Created attachment 58831 [details]
> a trial patch for c#129
>
> A quick fix may be:
>
> * config/sh/sh.md
> (call_pcrel, call_value_pcrel, sibcall_pcrel): Us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #166 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #164)
>
> R0 specific pass would be "the Right Thing". It is hard to do right away,
> though.
I know. It's not a quick-fix, needs more time to implement.
> I've se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #167 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #165)
> (In reply to Oleg Endo from comment #163)
> > (In reply to Kazumoto Kojima from comment #130)
> > > Created attachment 58831 [details]
> > > a trial patch for c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #177 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #175)
> (In reply to John Paul Adrian Glaubitz from comment #172)
> > ../../../src/libgcc/libgcc2.c:538:1: internal compiler error: Illegal
> > instruction
> > root@tir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #179 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #178)
> (In reply to Oleg Endo from comment #177)
> > As for bootstrapping, afaik Jeff Law has been bootstrapping vanilla sh4
> > compiler on a regular basis,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #191 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #188)
> (In reply to Kazumoto Kojima from comment #187)
>
> Looking at the RTL dumps in -mlra case, there is an instruction to set r4 in
> the postreload dump:
>
> (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #195 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #193)
Great results!
>
> It looks that LRA allocates r4 to the psuedo register r2854 and assumes that
> it's preserved beyond the insn 1752 block_lump_real_i4.
> Can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #220 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #219)
> (In reply to Oleg Endo from comment #217)
> > (In reply to Kazumoto Kojima from comment #216)
>
> > Kaz, can you please create a branch devel/sh-lra and add th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #217 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #216)
> Created attachment 59034 [details]
> a patch augments 58905
>
> In the problematic case c#214, the subreg pass requires to recognize the insn
>
> (insn 224 22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #222 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #221)
> (In reply to Oleg Endo from comment #220)
>
> > Ah, OK, understandable. No problem. How about github instead?
>
> I forked https://github.com/gcc-mirror/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #249 from Oleg Endo ---
(In reply to Kazumoto Kojima from comment #248)
> Created attachment 59102 [details]
> a reduced C test case for the wrong code problem c#192
>
> typedef struct { int c[64]; } obj;
>
> extern void bar (int, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #253 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #252)
> (In reply to John Paul Adrian Glaubitz from comment #250)
> > This builds fine. I will try to build Kaz's tree now as it is.
>
> I suggest, once this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #255 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #254)
> OK, thanks for the clarification. I'd suggest then to upstream everything
> that has been tested to work and is also fine to merge as-is.
Having the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #257 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #256)
> >
> > Having the compiler bootstrapping is already a big step, but how about
> > building other packages? With the patched up and bootstrapping comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116540
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116709
Bug ID: 116709
Summary: [SH] fp values ferried through fpul
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
Bug ID: 116713
Summary: [SH] __builtin_prefetch can't be used for store queues
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115949
--- Comment #5 from Oleg Endo ---
This issue seems to be popping up quite often when the fsca insn is utilized
(via the sincos pattern). That's the only insn which uses a `v2sf` (
vec2 ) and I suspect that something's going wrong there when it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #261 from Oleg Endo ---
I'm a little concerned because of PR 115949. It shows that there are some
fundamental issues with move patterns like `movsi_ie`. It seems real-world
code is very easy to hit that problem.
I'm thinking to rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116719
Bug ID: 116719
Summary: [SH] missed folding of fp factor constant
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
--- Comment #15 from Oleg Endo ---
It's been too long since I've looked into it. Maybe some middle-end parts got
more suitable over the time, but it was difficult to make it generate the fipr
instruction automatically due to the reasons stated a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55295
--- Comment #17 from Oleg Endo ---
(In reply to Luke Benstead from comment #16)
> OK so perhaps adding __builtin_sh_fipr is a good first step?
Yeah, you can try and see if it produces any useful results for you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115102
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #5 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #4)
> Created attachment 58244 [details]
> Preprocessed source from building read-vorbis.c with gcc-14 and -fverbose-asm
>
> (In reply to Oleg Endo from comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #7 from Oleg Endo ---
(In reply to Oleg Endo from comment #5)
>
> The following hunk seems to fix the ".align 1" following the short byte table
>
> diff --git a/gcc/config/sh/sh.cc b/gcc/config/sh/sh.cc
> index ef3c2e6791d..0134932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #8 from Oleg Endo ---
(In reply to Oleg Endo from comment #7)
> (In reply to Oleg Endo from comment #5)
> >
> > The following hunk seems to fix the ".align 1" following the short byte
> > table
> >
> > diff --git a/gcc/config/sh/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #9 from Oleg Endo ---
(In reply to Oleg Endo from comment #8)
>
> It looks like something dpulicates the ".align 1" directive after the byte
> table and then also duplicates it. Perhaps the directive is treated wrongly
> as an insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #11 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #10)
>
> Yes, definitely. Will take a little longer though as I need to fix my setup
> first.
Thanks in advance. Wait for your update.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
Oleg Endo changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115148
--- Comment #16 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #15)
> Created attachment 58258 [details]
> Diff of generated assembly without and with changes from PR99531
>
> I have generated a diff that shows the diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99531
--- Comment #12 from Oleg Endo ---
(In reply to Oleg Endo from comment #11)
>
> This caused PR 115148
I absolutely lack the imagination to see the connection of the change in #c6
and PR 115148. This is the change in the output code that result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59291
Oleg Endo changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107704
--- Comment #5 from Oleg Endo ---
(In reply to Jeffrey A. Law from comment #2)
> ACK. And as I mentioned, the RTL form looks like it ought to be caught by
> the SH specific code to optimize T reg handling. I don't care enough about
> the SH to
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 bus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
Oleg Endo changed:
What|Removed |Added
Last reconfirmed||2023-10-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #3 from Oleg Endo ---
(In reply to Oleg Endo from comment #2)
> I've briefly tried on a local gcc version 13.1.1 20230714
>
> While it doesn't crash, the sh_treg_combine2 pass seems to be stuck in an
> infinite loop. It produces a
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
> prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81426
--- Comment #12 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> Created attachment 56123 [details]
> Preprocessed source from building GHC with gcc-13
>
> This is still present in gcc-13, I just ran into it while cr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
Oleg Endo changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101177
--- Comment #13 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #12)
>
> That was super-fast! Thanks a lot!
Not really. ~2 years from patch to commit. Sorry about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892
Oleg Endo changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Oleg Endo ---
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51708
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #4 from Oleg Endo ---
Created attachment 56164
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164&action=edit
sh_pr11001_fix.patch
Can you please try this patch? It should solve the problem, but not sure if
there could be a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111892
--- Comment #5 from Oleg Endo ---
Adrian, can you please give it another go with the patch I've posted in PR
111001 ?
https://gcc.gnu.org/bugzilla/attachment.cgi?id=56164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65250
--- Comment #2 from Oleg Endo ---
Briefly checked this one on GCC-13. It generates the optimal sequence.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #7 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #5)
>
> I can confirm that this patch fixes the build of e2fsprogs with gcc-13 for
> me.
Great, thanks! Do you have an option to run a compiler bootstrap or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #9 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #8)
>
> I built gcc-13 natively with the patch applied with a full bootstrap
> including stage2 and stage3. Full build log available in [1].
>
> > [1] https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #15 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #10)
>
> Do we need anything else before the fix can be merged?
No, should be fine. I'll leave this PR open for a while in case anything else
related pops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111001
--- Comment #17 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #16)
> Just saw the branch updates, thanks! FWIW, I did observe this issue in
> gcc-13 only but not gcc-11 or gcc-12. But that might be owed to the fact
> th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93808
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #34 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #33)
> Created attachment 55142 [details]
> Disable dynamic shift instructions patch
First of all, thanks for digging into this. This issue has been a can of
worms,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #36 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #35)
>
> As I understand, you meant the following (I added new functions at the end
> of file):
>
> $ cat f.c
> #define ADDR 0x
> #define P ((unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #38 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #37)
>
> As far as I understand from GCC sources, function I patched
> 'expand_ashiftrt' process only constant values of shift. As you can see
> earlier, I added you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #40 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #39)
>
> I'm sorry, but .md lang is too complicated for me.
Yeah, it looks alien at first sight. But it's where a lot of things happen
w.r.t. instruction selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #42 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #41)
>
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #44 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #43)
>
> Well, not really. Look what's happening during expand pass when 'ashrsi3' is
> expanding. Function 'expand_ashiftrt' is called and what it does at the end
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #47 from Oleg Endo ---
(In reply to Eric Gallager from comment #46)
> Reminder that patches go to the gcc-patches mailing list
It's OK. We're just throwing around ideas, nothing final
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #49 from Oleg Endo ---
(In reply to Alexander Klepikov from comment #48)
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #50 from Oleg Endo ---
Actually, let's take any further discussion of shift patterns to PR 54089.
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 shor
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
> "a
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
> instr
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 func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517
--- Comment #13 from Oleg Endo ---
(In reply to Andrew Pinski from comment #12)
> Created attachment 55239 [details]
> Patch which does work on this
>
> Though, I need to double to make sure it works for other cases still.
> sh is the case where
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=58517
--- Comment #17 from Oleg Endo ---
(In reply to Andrew Pinski from comment #16)
> Now I am curious if T_REG should be BImode rather than SImode ... Then
> ifcvt.cc would not have to be modified. I Know BImode is newer than when sh
> target was ad
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
> blo
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 #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
> patche
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 p
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 t
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 wh
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
> des
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 #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 #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 #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 #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 set
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=109874
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65162
--- Comment #13 from Oleg Endo ---
(In reply to Oleg Endo from comment #1)
> (In reply to Oleg Endo from comment #0)
> > The following example is taken from libav, which contains quite some uses of
> > this code pattern.
> >
> > typedef unsigned
1 - 100 of 232 matches
Mail list logo
