public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/36503] New: x86 can use x >> -y for x >> 32-y
@ 2008-06-11 22:53 astrange at ithinksw dot com
2008-06-11 22:53 ` [Bug target/36503] " astrange at ithinksw dot com
` (6 more replies)
0 siblings, 7 replies; 10+ messages in thread
From: astrange at ithinksw dot com @ 2008-06-11 22:53 UTC (permalink / raw)
To: gcc-bugs
> gcc -v
Using built-in specs.
Target: i386-apple-darwin9.2.2
Configured with: ../gcc/configure --prefix=/usr/local/gcc44
--enable-threads=posix --with-arch=core2 --with-tune=core2 --with-gmp=/sw
--with-mpfr=/sw --disable-nls --disable-bootstrap --enable-checking=yes,rtl
--enable-languages=c,c++,objc
Thread model: posix
gcc version 4.4.0 20080611 (experimental) (GCC)
gcc compiles
int shift32(int i, int n)
{
return i >> (32 - n);
}
to
_shift32:
subl $12, %esp
movl $32, %ecx
subl 20(%esp), %ecx
movl 16(%esp), %eax
sarl %cl, %eax
addl $12, %esp
ret
Since all 286-and-up CPUs only use the low 5 bits of ecx when shifting, this
can be:
_shift32:
movl 8(%esp), %ecx
movl 4(%esp), %eax
negl %ecx
sarl %cl, %eax
ret
This is very common in bitstream readers, where it's used to read the top N
bits from a word. ffmpeg already has an inline asm to do it, which I'd like to
get rid of.
I'd guess this applies to some other architectures; it probably works on
x86-64, but doesn't on PPC.
--
Summary: x86 can use x >> -y for x >> 32-y
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: astrange at ithinksw dot com
GCC target triplet: i?86-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
@ 2008-06-11 22:53 ` astrange at ithinksw dot com
2008-06-12 0:05 ` pinskia at gcc dot gnu dot org
` (5 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: astrange at ithinksw dot com @ 2008-06-11 22:53 UTC (permalink / raw)
To: gcc-bugs
--
astrange at ithinksw dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
2008-06-11 22:53 ` [Bug target/36503] " astrange at ithinksw dot com
@ 2008-06-12 0:05 ` pinskia at gcc dot gnu dot org
2008-06-12 9:25 ` rguenth at gcc dot gnu dot org
` (4 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2008-06-12 0:05 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pinskia at gcc dot gnu dot org 2008-06-12 00:05 -------
>I'd guess this applies to some other architectures;
Not really. It depends on the definition of the shift. Most targets have
undefined values are produced from negative shifts values.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
2008-06-11 22:53 ` [Bug target/36503] " astrange at ithinksw dot com
2008-06-12 0:05 ` pinskia at gcc dot gnu dot org
@ 2008-06-12 9:25 ` rguenth at gcc dot gnu dot org
2008-06-12 10:44 ` ubizjak at gmail dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2008-06-12 9:25 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from rguenth at gcc dot gnu dot org 2008-06-12 09:25 -------
We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if
that says negative values are ok).
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords| |missed-optimization
Last reconfirmed|0000-00-00 00:00:00 |2008-06-12 09:25:00
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
` (2 preceding siblings ...)
2008-06-12 9:25 ` rguenth at gcc dot gnu dot org
@ 2008-06-12 10:44 ` ubizjak at gmail dot com
2008-06-12 16:49 ` astrange at ithinksw dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 10+ messages in thread
From: ubizjak at gmail dot com @ 2008-06-12 10:44 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from ubizjak at gmail dot com 2008-06-12 10:43 -------
(In reply to comment #2)
> We have the SHIFT_COUNT_TRUNCATED macro for this (though I'm not sure if
> that says negative values are ok).
They are, but there is a comment in the documentation:
-- Macro: SHIFT_COUNT_TRUNCATED
...
However, on some machines, such as the 80386 and the 680x0,
truncation only applies to shift operations and not the (real or
pretended) bit-field operations. Define `SHIFT_COUNT_TRUNCATED'
to be zero on such machines. Instead, add patterns to the `md'
file that include the implied truncation of the shift instructions.
I don't know which "real or pretended" bit-field operations are referred here,
since bt insn also truncate its bit-offset operand. OTOH, {SI,HI,QI}mode shifts
all truncate to 0x1f, not to GET_MODE_SIZE(mode) - 1.
I have a patch:
Index: config/i386/i386.c
===================================================================
--- config/i386/i386.c (revision 136692)
+++ config/i386/i386.c (working copy)
@@ -24681,6 +24681,22 @@
emit_insn (fn (dest, tmp2, tmp3));
}
+/* Target hook for target_shift_trucnation_mask. */
+static unsigned HOST_WIDE_INT
+ix86_shift_truncation_mask (enum machine_mode mode)
+{
+ if (TARGET_64BIT
+ && mode == DImode)
+ return 0x3f;
+
+ if (mode == SImode
+ || mode == HImode
+ || mode == QImode)
+ return 0x1f;
+
+ return 0;
+}
+
/* Target hook for scalar_mode_supported_p. */
static bool
ix86_scalar_mode_supported_p (enum machine_mode mode)
@@ -26039,6 +26055,9 @@
#undef TARGET_GIMPLIFY_VA_ARG_EXPR
#define TARGET_GIMPLIFY_VA_ARG_EXPR ix86_gimplify_va_arg
+#undef TARGET_SHIFT_TRUNCATION_MASK
+#define TARGET_SHIFT_TRUNCATION_MASK ix86_shift_truncation_mask
+
#undef TARGET_SCALAR_MODE_SUPPORTED_P
#define TARGET_SCALAR_MODE_SUPPORTED_P ix86_scalar_mode_supported_p
But it does nothing for this optimization. I guess middle-end should be kicked
to handle this optimization.
BTW: Why does ffmpeg need inline asm for this optimization? Following code
snipped also produces expected code:
int shift32 (int i, int n)
{
return i >> (-n);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
` (3 preceding siblings ...)
2008-06-12 10:44 ` ubizjak at gmail dot com
@ 2008-06-12 16:49 ` astrange at ithinksw dot com
2009-11-07 9:22 ` bonzini at gnu dot org
2009-11-09 7:38 ` ubizjak at gmail dot com
6 siblings, 0 replies; 10+ messages in thread
From: astrange at ithinksw dot com @ 2008-06-12 16:49 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from astrange at ithinksw dot com 2008-06-12 16:48 -------
Maybe it seemed likely to cause a warning - I haven't checked that yet, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
` (4 preceding siblings ...)
2008-06-12 16:49 ` astrange at ithinksw dot com
@ 2009-11-07 9:22 ` bonzini at gnu dot org
2009-11-09 7:38 ` ubizjak at gmail dot com
6 siblings, 0 replies; 10+ messages in thread
From: bonzini at gnu dot org @ 2009-11-07 9:22 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from bonzini at gnu dot org 2009-11-07 09:21 -------
bt with a memory object and a register index will _not_ truncate the argument:
static int btm(int *a, int b) {
asm ("btl %2, %1; movl $0, %0; setc %b0" : "=r" (b) : "m" (*a), "0" (b));
return b;
}
static int btr(int a, int b) {
asm ("btl %2, %1; movl $0, %0; setc %b0" : "=r" (b) : "r" (a), "0" (b));
return b;
}
#define btmi(a, b) ({ int __x; \
asm ("btl %2, %1; movl $0, %0; setc %b0" : "=r" (__x) : "m" (*a), "i" (b)); \
__x; \
})
int main () {
int y[3] = { 0x5, 0, 0x5 };
printf ("bt %%reg, %%reg: %d %d %d\n", btr(5, 0), btr(5, 32), btr(5, 64));
printf ("bt $bit, (mem): %d %d %d\n", btmi(y, 0), btmi(y, 32), btmi(y, 64));
printf ("bt %%reg, (mem): %d %d %d\n", btm(y, 0), btm(y, 32), btm(y, 64));
}
>> bt %reg, %reg: 1 1 1
>> bt $val, (mem): 1 1 1
>> bt %reg, (mem): 1 0 1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
` (5 preceding siblings ...)
2009-11-07 9:22 ` bonzini at gnu dot org
@ 2009-11-09 7:38 ` ubizjak at gmail dot com
6 siblings, 0 replies; 10+ messages in thread
From: ubizjak at gmail dot com @ 2009-11-09 7:38 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from ubizjak at gmail dot com 2009-11-09 07:38 -------
(In reply to comment #5)
> bt with a memory object and a register index will _not_ truncate the argument:
Actually, we avoid bt with memory objects just because of this (handling of
memory op is not consistent with register op). Please look at i386.md.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
[not found] <bug-36503-4@http.gcc.gnu.org/bugzilla/>
2010-10-21 4:39 ` astrange at ithinksw dot com
@ 2010-10-22 7:37 ` ubizjak at gmail dot com
1 sibling, 0 replies; 10+ messages in thread
From: ubizjak at gmail dot com @ 2010-10-22 7:37 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
--- Comment #9 from Uros Bizjak <ubizjak at gmail dot com> 2010-10-22 07:37:22 UTC ---
(In reply to comment #8)
> I built ffmpeg for x86-64 with --disable-asm with the attached patch and the
> regression tests failed. Reverting the patch fixes them. I saved the binaries
> but haven't investigated yet.
The problem is that new insn pattern clobbers %ecx. Currently, this is not
modeled correctly - if this is fixed, then the combine doesn't recognize
combined pattern. So, either combine should be fixed to allow correct
(match_dup X) in the combined pattern or this transformation should be
implemented in generic part of the compiler.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug target/36503] x86 can use x >> -y for x >> 32-y
[not found] <bug-36503-4@http.gcc.gnu.org/bugzilla/>
@ 2010-10-21 4:39 ` astrange at ithinksw dot com
2010-10-22 7:37 ` ubizjak at gmail dot com
1 sibling, 0 replies; 10+ messages in thread
From: astrange at ithinksw dot com @ 2010-10-21 4:39 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36503
--- Comment #8 from Alexander Strange <astrange at ithinksw dot com> 2010-10-21 04:39:36 UTC ---
I built ffmpeg for x86-64 with --disable-asm with the attached patch and the
regression tests failed. Reverting the patch fixes them. I saved the binaries
but haven't investigated yet.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-10-22 7:37 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-11 22:53 [Bug target/36503] New: x86 can use x >> -y for x >> 32-y astrange at ithinksw dot com
2008-06-11 22:53 ` [Bug target/36503] " astrange at ithinksw dot com
2008-06-12 0:05 ` pinskia at gcc dot gnu dot org
2008-06-12 9:25 ` rguenth at gcc dot gnu dot org
2008-06-12 10:44 ` ubizjak at gmail dot com
2008-06-12 16:49 ` astrange at ithinksw dot com
2009-11-07 9:22 ` bonzini at gnu dot org
2009-11-09 7:38 ` ubizjak at gmail dot com
[not found] <bug-36503-4@http.gcc.gnu.org/bugzilla/>
2010-10-21 4:39 ` astrange at ithinksw dot com
2010-10-22 7:37 ` ubizjak at gmail dot com
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).