This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/54673] [SH] Unnecessary sign extension of logical operation results
- From: "olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 27 Oct 2012 13:15:12 +0000
- Subject: [Bug target/54673] [SH] Unnecessary sign extension of logical operation results
- Auto-submitted: auto-generated
- References: <bug-54673-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54673
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2012-10-27
AssignedTo|unassigned at gcc dot |olegendo at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-10-27 13:15:12 UTC ---
Created attachment 28542
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28542
WIP patch (little endian only)
I've been trying out a couple of things. It seems that disallowing subregs in
operands of logical ops introduces other missed optimization opportunities,
such as:
void test02452 (unsigned char* a, int* b, int c)
{
b[0] = a[0] & 251;
}
where this would expand into something like 'a[0] & -5' and the 'and #imm,r0'
insn would thus not be used.
The actual problem seems to be the original expansion of memory loads, where
sometimes e.g. the movqi pattern is used to load a QImode mem into a QImode reg
without zero/sign extensions. Thus subsequent uses of the loaded mem do not
know that it's been sign-extended by the load.
The attached patch fixes this in the movqi / movhi expanders and the redundant
extensions disappear. However, it has an impact on the tst insns and overall
register allocation. The tst insns cases can be handled by a few additional
patterns, but the register allocation issue leads to a couple of rather huge
code size increases in some of the CSiBE files (-O2 -m4-single -ml
-mpretend-cmove), with the following peaks:
bzip2-1.0.2
compress 12172 -> 12708 +536 / +4.403549 %
mpeg2dec-0.3.1
libmpeg2/motion_comp 4860 -> 5020 +160 / +3.292181 %
libvo/yuv2rgb 3856 -> 4056 +200 / +5.186722 %