, "bt %reg, 75" will not return 0, but shift insn
with the same operands will.
Yes, only for memory_operands.
You can take a look at the attached patch. I never got round to finish
it, but I think it bootstrapped. It unifies SHIFT_COUNT_TRUNCATED and
TARGET_SHIFT_TRUNCATION_MASK, I
On Thu, Jul 15, 2010 at 2:16 PM, Paolo Bonzini wrote:
> On 07/15/2010 09:57 AM, Uros Bizjak wrote:
>>
>> Hello!
>>
>> I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
>> hope that redundant masking would get eliminated from:
>>
>> in
On 07/15/2010 09:57 AM, Uros Bizjak wrote:
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a<< (c& 0x1f);
}
The macro was defined as:
+/*
Hello!
I was playing a bit with TARGET_SHIFT_TRUNCATION_MASK on x86 in the
hope that redundant masking would get eliminated from:
int test (int a, int c)
{
return a << (c & 0x1f);
}
The macro was defined as:
+/* Implement TARGET_SHIFT_TRUNCATION_MASK. */
+static unsigned HOS
Andreas Krebbel <[EMAIL PROTECTED]> writes:
> In:
> http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00456.html
>
> you proposed to take care of this in the 4.1 (formerly 3.6) timeframe fixing
> all places where shift rtxes are generated besides optabs.
> Is this still on your todo list?
Yes, but so a
Hi Richard,
I've recently experimented with TARGET_SHIFT_TRUNCATION_MASK
macro and have posted a patch defining it for S/390.
On S/390 only the least significant six bits of a shift count
operand are used and I therefore expected the modulo operation
in the following example to be opti
