http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Oleg Endo changed:
What|Removed |Added
Attachment #24625|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #7 from Oleg Endo 2011-10-09 23:34:45 UTC
---
(In reply to comment #6)
> Yep, maintenance burden but I don't mean ack/nak for anything.
> If it's enough fruitful, we should take that route. When it
> gives 5% improvement in the usua
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #9 from Oleg Endo 2011-10-10 23:48:17 UTC
---
Created attachment 25461
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25461
CSiBE comparisons
(In reply to comment #8)
>
> Another combine pass to reduce size less than 0.3% on on
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
While testing a patch I have noticed some failures for SH2A and -ml.
The problem is that GCC happily generates SH2A code in little endian, but
when the output is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #1 from Oleg Endo 2011-10-13 19:54:31 UTC
---
As it turns out, this is already handled by the line
#define DRIVER_SELF_SPECS "%{m2a:%{ml:%eSH2a does not support little-endian}}"
in sh.h.
However, it doesn't catch -m2a-nofpu, -m2a-s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
Oleg Endo changed:
What|Removed |Added
Attachment #24412|0 |1
is obsolete|
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Post-increment addressing is generated only for the first
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Pre-decrement addressing is generated only for the first
: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Displacement addressing is only used for SImode but not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #2 from Oleg Endo 2011-10-17 00:37:42 UTC
---
(In reply to comment #1)
> This is a known issue. See the comment just before
> sh.c:sh_legitimate_index_p.
> Unfortunately, I guess this PR might be marked as WONTFIX.
Yeah, I know thi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #3 from Oleg Endo 2011-10-18 21:33:06 UTC
---
(In reply to comment #2)
> Ah. One liner
>
> -#define DRIVER_SELF_SPECS "%{m2a:%{ml:%eSH2a does not support
> little-endian}}"
> +#define DRIVER_SELF_SPECS "%{m2a*:%{ml:%eSH2a does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #5 from Oleg Endo 2011-10-18 22:37:13 UTC
---
(In reply to comment #4)
> There are no real uses of SH1/SH2/SH2E/SH3E cores anymore, I think.
True. But the SH7020 (SH1) is still listed on digikey for an amazing
collector's price ;)
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #3 from Oleg Endo 2011-10-19 00:00:01 UTC
---
Kaz,
do you happen to know why the following is defined in sh.h?
#define USE_LOAD_POST_INCREMENT(mode)((mode == SImode || mode == DImode) \
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #7 from Oleg Endo 2011-10-20 18:44:32 UTC
---
(In reply to comment #6)
> (In reply to comment #5)
> > I'll send in a patch with a couple of other cosmetic changes later, OK?
>
> Please go for it.
..or maybe just leave it as it is :T
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh2a-*-*
Although there are some insns (e.g. ashlsi3_sh2a) that are supposed to handle
dynamic shifts on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #4 from Oleg Endo 2011-10-23 21:56:56 UTC
---
Created attachment 25582
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25582
Experimental patch for mov.b with displacement addressing
> (In reply to comment #2)
>
> Welcome to the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #6 from Oleg Endo 2011-10-26 22:36:31 UTC
---
Created attachment 25621
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25621
Experimental not working patch for mov.b with displacement addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #7 from Oleg Endo 2011-10-26 23:07:08 UTC
---
Created attachment 25622
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25622
asmcons and ira pass log for the reload failure of "z" insn constraint
(In reply to comment #5)
> It see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #9 from Oleg Endo 2011-10-27 09:23:47 UTC
---
Created attachment 25625
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25625
Stripped reload test case from bzip2
(In reply to comment #8)
>
> and RA chooses r1 and r0 as the regis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #10 from Oleg Endo 2011-10-27 21:10:47 UTC
---
@@ -12430,6 +12453,10 @@ sh_secondary_reload (bool in_p, rtx x, r
if (rclass != GENERAL_REGS && REG_P (x)
&& TARGET_REGISTER_P (REGNO (x)))
return GENERAL_REGS;
+ if (rcla
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #11 from Oleg Endo 2011-10-27 21:54:17 UTC
---
Created attachment 25639
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25639
Stripped reload test case from jpeg-6b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #5 from Oleg Endo 2011-10-30 12:36:51 UTC
---
(In reply to comment #4)
>
> I'm a bit curious to see what happens if they are changed
> to non-zero for SI/DImode.
..not much actually. I've tried defining both as TARGET_SH1 and compar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50694
--- Comment #9 from Oleg Endo 2011-10-30 12:45:30 UTC
---
(In reply to comment #8)
> (In reply to comment #7)
>
> This problem doesn't require the theoretical/mathematical
> completeness. There are many inappropriate combinations
> of options w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #6 from Oleg Endo 2011-10-30 13:53:51 UTC
---
(In reply to comment #1)
> GCC makes usual mem accesses into those with post_inc/pre_dec at
> auto_inc_dec pass. I guess that auto_inc_dec pass can't find
> post_inc insns well in that ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #13 from Oleg Endo 2011-11-02 00:15:44 UTC
---
Created attachment 25684
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25684
Proposed patch to add QImode displacement addressing
This should be better now. I have also put back s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #15 from Oleg Endo 2011-11-02 01:38:26 UTC
---
(In reply to comment #14)
> .ira dump would be your friend, though I suspect that your patch
> triggered off some other reload problem like PR48596. Could you
> try the change in #5 of t
: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
I'm not sure whether this is valid/invalid C++11, but it seems a little weird.
The following works as expected:
struct B
{
constexpr B (unsigned v) noexcept : v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
Oleg Endo changed:
What|Removed |Added
Attachment #25684|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #14 from Oleg Endo 2011-11-20 13:04:39 UTC
---
With trunk rev 181517 I have observed the following problem, which happens when
compiling for -m2*, -m3*, -m4* and -Os:
The function compiled with -m2 -Os
int test_int64_lowword (long l
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Created attachment 25868
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25868
Examples
Under s
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Created attachment 25869
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25869
Examples
It seems t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
Oleg Endo changed:
What|Removed |Added
CC||oleg.e...@t-online.de
--- Comment #19 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50814
--- Comment #2 from Oleg Endo 2011-11-27 22:38:34 UTC
---
(In reply to comment #1)
> Will be slightly different because sh2a's shad&shld are 4-byte
> insns. Perhaps something like below will work, though I don't
> test it at all.
>
According
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
Oleg Endo changed:
What|Removed |Added
Attachment #25848|0 |1
is obsolete|
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh2a-*-*
There are various testsuite ICEs for -m2a -mb -O0, which look similar to the
following:
gcc.c-torture
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
Currently the FMAC insn has to be enabled by specifying the -mfused-madd
option. Is there any
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #8 from Oleg Endo 2011-11-28 22:31:44 UTC
---
(In reply to comment #7)
> The problem is that SH target can't do those simple array accesses
> well at QI/HImode because of the lack of displacement addressing
> for those modes.
In thes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
Oleg Endo changed:
What|Removed |Added
Attachment #25932|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #20 from Oleg Endo 2011-12-12 02:11:12 UTC
---
(In reply to comment #19)
> The results look way better now. I've tested your latest patch for
> sh4-unknown-linux-gnu and found no new regressions for gcc testsuite.
> CSiBE with "-O2 -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340
--- Comment #2 from Oleg Endo 2011-12-19 01:29:12 UTC
---
(In reply to comment #1)
> (In reply to comment #0)
> > Is there any particular reason why this should not be enabled by
> > default for SH targets that support the FMAC insn?
>
> PR29100
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #2 from Oleg Endo 2011-12-27 21:26:33 UTC
---
(In reply to comment #1)
>
> BTW, OT, (a != b || a != c) ? b : c could be reduced to b, I think.
>
Yes, very much so.
It is reduced to "return b" for -m2, -m2e, -m2a, -m3, -m3e
but not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #3 from Oleg Endo 2011-12-27 22:43:11 UTC
---
Created attachment 26191
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26191
Proposed patch to improve some of the issues.
(In reply to comment #1)
>
> [...]
>
> mov #-1,rn
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #4 from Oleg Endo 2011-12-27 23:17:03 UTC
---
(In reply to comment #1)
>
> > return a >= 0 && b >= 0 ? c : d;
>
> x >= 0 is expanded to the sequence like
>
> ra = not x
> rb = -31
> rc = ra >> (neg rb)
> T = (rc == 0)
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #5 from Oleg Endo 2011-12-28 02:44:05 UTC
---
(In reply to comment #2)
> (In reply to comment #1)
> >
> > BTW, OT, (a != b || a != c) ? b : c could be reduced to b, I think.
> >
>
> Yes, very much so.
> It is reduced to "return b"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #6 from Oleg Endo 2011-12-28 15:59:35 UTC
---
(In reply to comment #3)
> Created attachment 26191 [details]
> Proposed patch to improve some of the issues.
>
> The attached patch removes the useless sequence and still allows the -1
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51340
--- Comment #4 from Oleg Endo 2011-12-29 00:02:40 UTC
---
(In reply to comment #3)
> (In reply to comment #2)
> > Uhm, yes...
> > The title should have been "Enable -mfused-madd by -ffast-math"
>
> Do you mean something like this?
>
> --- ORIG/
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
For -Os and everything but -m1 DImode comparisons are not optimized properly
which results in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #15 from Oleg Endo 2011-12-29 00:34:53 UTC
---
(In reply to comment #14)
> With trunk rev 181517 I have observed the following problem, which happens
> when
> compiling for -m2*, -m3*, -m4* and -Os:
>
This is still present as of re
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
Target: sh*-*-*
If the shift amount is a constant for SHAD / SHLD insns it should be CSE-ed.
This could be done in a similar way as in the movnegt insn.
Example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
--- Comment #10 from Oleg Endo 2011-12-30 02:14:00 UTC
---
(In reply to comment #9)
> (In reply to comment #8)
> > Specifying -fno-tree-forwprop doesn't seem to have any effect on these
> > cases.
>
> For that function, -fdump-tree-all shows th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #8 from Oleg Endo 2011-12-30 21:21:14 UTC
---
(In reply to comment #7)
> (In reply to comment #3)
> > I haven't ran all tests on it yet, but CSiBE shows average code size
> > reduction
> > of approx. -0.1% for -m4* with some code siz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31640
--- Comment #3 from Oleg Endo 2011-12-31 17:24:47 UTC
---
Created attachment 26208
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26208
Proposed patch
(In reply to comment #0)
> The sh4 port aligns blocks that have no fallthrus and that are
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
CC: kkoj...@gcc.gnu.org
Target: sh*-*-*
static volatile int* const g_0 = (volatile int*)0x1240;
static volatile int* const g_1 = (volatile int
nt: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
Created attachment 24411
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24411
test for various integer types and constant values 0...255
The "TST #imm, R0" instruction is a bit underutilized on S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #1 from Oleg Endo 2011-06-01 20:42:00 UTC
---
Created attachment 24412
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24412
Proposed Patch
Although the patch gets the job done, programmer's sense tells me it is fishy,
or at leas
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
When building newlib 1.19.0 it fails to build the SH2A lib:
sh-elf-gcc -B/home/y/code/gcc/newlib-1.19.0-build-sh-elf/sh-elf/m2a/newlib/
-isystem
/home/y/code/gcc/newlib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
--- Comment #2 from Oleg Endo 2011-06-19 15:48:41 UTC
---
Created attachment 24561
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24561
Before/After Examples
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #3 from Oleg Endo 2011-06-19 16:42:01 UTC
---
Thanks for having a look at it Kaz.
Yes, the fiddling with the combine pass is fragile. I've tried out your
peephole idea. It works in most cases but not all the time. E.g. it doesn't
catc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
--- Comment #1 from Oleg Endo 2011-06-19 15:29:45 UTC
---
Created attachment 24560
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24560
Proposed patch
The patch adds explicit handling of abs:SI and abs:DI to the machine
description instead
...@gcc.gnu.org
ReportedBy: oleg.e...@t-online.de
The generated code for abs:SI and abs:DI is a bit inefficient:
int abs (int i)
{
return (i < 0) ? -i : i;
}
movr4,r1
shllr1
subcr1,r1
movr1,r0
xorr4,r0
rts
subr1,r0
long long abs (long long i)
{
return (i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Oleg Endo changed:
What|Removed |Added
Attachment #24560|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49263
--- Comment #5 from Oleg Endo 2011-06-26 22:30:05 UTC
---
> Yes, that peephole doesn't catch all the patterns which could
> make tst #imm8,r0 use. Perhaps it would be a good idea to get
> numbers for the test like CSiBE test with the vanilla and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49468
Oleg Endo changed:
What|Removed |Added
Attachment #24603|0 |1
is obsolete|
63 matches
Mail list logo
