public inbox for java-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug rtl-optimization/17731] sub-optimal code generated for left shift
[not found] <bug-17731-8172@http.gcc.gnu.org/bugzilla/>
@ 2011-05-22 15:52 ` steven at gcc dot gnu.org
0 siblings, 0 replies; 3+ messages in thread
From: steven at gcc dot gnu.org @ 2011-05-22 15:52 UTC (permalink / raw)
To: java-prs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17731
Steven Bosscher <steven at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Last reconfirmed|2006-01-16 06:19:32 |2011-05-22 17:27:32
Resolution| |FIXED
--- Comment #8 from Steven Bosscher <steven at gcc dot gnu.org> 2011-05-22 15:30:58 UTC ---
(In reply to comment #2)
> Yes, that's fine.
> The java front end generates trees like <shift op <and op 31>>.
> I would like the extra "and" to be optimized out somewhere
> along the way, on a target-specific basis.
Fixed by tree-ssa::
$ cat t.c
int shift (int x, int y)
{
int _y = y & 31;
return x << _y;
}
$ ./cc1 -quiet -m32 -O2 t.c -fdump-tree-optimized
$ cat t.s
.file "t.c"
.text
.p2align 4,,15
.globl shift
.type shift, @function
shift:
.LFB0:
.cfi_startproc
movl 4(%esp), %eax
movl 8(%esp), %ecx
sall %cl, %eax
ret
.cfi_endproc
.LFE0:
.size shift, .-shift
.ident "GCC: (GNU) 4.6.0 20110312 (experimental) [trunk revision
170907]"
.section .note.GNU-stack,"",@progbits
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug java/17731] New: sub-optimal code generated for left shift
@ 2004-09-29 17:58 tromey at gcc dot gnu dot org
2004-09-29 19:39 ` [Bug rtl-optimization/17731] " rth at gcc dot gnu dot org
2004-09-29 21:03 ` tromey at gcc dot gnu dot org
0 siblings, 2 replies; 3+ messages in thread
From: tromey at gcc dot gnu dot org @ 2004-09-29 17:58 UTC (permalink / raw)
To: java-prs
Consider this java method:
public int shift (int x, int y)
{
return x << y;
}
On x86, with -O3, this becomes:
_ZN1t5shiftEii:
.LFB2:
pushl %ebp
.LCFI0:
movl %esp, %ebp
.LCFI1:
movl 16(%ebp), %ecx
movl 12(%ebp), %eax
popl %ebp
andl $31, %ecx
sall %cl, %eax
ret
However, on x86 (starting with 80286), the shift count is masked
to 5 bits by sall, so the "andl" instruction is redundant.
I haven't looked to see exactly where this buglet might lie.
--
Summary: sub-optimal code generated for left shift
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tromey at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17731
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/17731] sub-optimal code generated for left shift
2004-09-29 17:58 [Bug java/17731] New: " tromey at gcc dot gnu dot org
@ 2004-09-29 19:39 ` rth at gcc dot gnu dot org
2004-09-29 21:03 ` tromey at gcc dot gnu dot org
1 sibling, 0 replies; 3+ messages in thread
From: rth at gcc dot gnu dot org @ 2004-09-29 19:39 UTC (permalink / raw)
To: java-prs
------- Additional Comments From rth at gcc dot gnu dot org 2004-09-29 19:39 -------
This will be done properly if SHIFT_COUNT_TRUNCATED is true.
The problem is that SHIFT_COUNT_TRUNCATED applies to *all* shifts and at
the given mode size. Which is not true for x86, since HImode shifts are
still masked to 31, not 15.
Ideally we'd extend Richard Sandiford's new target.shift_truncation_mask
such that it can replace SHIFT_COUNT_TRUNCATED.
In the short term, Java could examine shift_truncation_mask and avoid
creating the AND at the tree level in the first place.
Not sure whether "middle-end" or "rtl-opt" is a better category, but this
is definitely not target-specific and thus "target" doesn't apply.
--
What |Removed |Added
----------------------------------------------------------------------------
Component|target |rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17731
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug rtl-optimization/17731] sub-optimal code generated for left shift
2004-09-29 17:58 [Bug java/17731] New: " tromey at gcc dot gnu dot org
2004-09-29 19:39 ` [Bug rtl-optimization/17731] " rth at gcc dot gnu dot org
@ 2004-09-29 21:03 ` tromey at gcc dot gnu dot org
1 sibling, 0 replies; 3+ messages in thread
From: tromey at gcc dot gnu dot org @ 2004-09-29 21:03 UTC (permalink / raw)
To: java-prs
------- Additional Comments From tromey at gcc dot gnu dot org 2004-09-29 21:03 -------
Thanks for the response.
I'm not too concerned in the short run -- we've had this bug for a
long time.
I neglected to mention that in java a long (64 bit, i.e. long << int)
shift uses "& 63" (as one would expect). I didn't look to see
what kind of code this generates or whether it can be further optimized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17731
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-05-22 15:52 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-17731-8172@http.gcc.gnu.org/bugzilla/>
2011-05-22 15:52 ` [Bug rtl-optimization/17731] sub-optimal code generated for left shift steven at gcc dot gnu.org
2004-09-29 17:58 [Bug java/17731] New: " tromey at gcc dot gnu dot org
2004-09-29 19:39 ` [Bug rtl-optimization/17731] " rth at gcc dot gnu dot org
2004-09-29 21:03 ` tromey at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).