On Mar 13, 2009, Paolo Bonzini wrote:
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
FR-V non-vector shifts truncate a register shift count to 5 bits; it's
from the ISA specs, it doesn't appear that the same truncat
On Fri, Mar 13, 2009 at 06:06:41PM +0100, Paolo Bonzini wrote:
>
> >>> Hm. In fold-const.c we try to make sure to produce the same result
> >>> as the target would for constant-folding shifts. Thus, Paolo, I think
> >>> what fold-const.c does is what we should assume for
> >>> !SHIFT_COUNT_TRUNC
On 3/16/09, Paolo Bonzini wrote:
>AND R1, R0, #31
>MOV R2, R2, SHIFT R1
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #31
>MOVNE R2, R2, SHIFT #1
>
> or
>
>ANDS R1, R0, #32
>MOVNE R2, R2, SHIFT #-32
>SUB R1, R1, R0 ; R1 = (x >= 32 ? 32 - x : -x)
>MOV R2,
Martin Guy wrote:
> On 3/14/09, Paolo Bonzini wrote:
>> Hans-Peter Nilsson wrote:
>> > The answer to the question is "no", but I'd guess the more
>> > useful answer is "yes", for different definitions of "truncate".
>>
>> Ok, after my patches you will be able to teach GCC about this definition
>
On 3/14/09, Paolo Bonzini wrote:
> Hans-Peter Nilsson wrote:
> > The answer to the question is "no", but I'd guess the more
> > useful answer is "yes", for different definitions of "truncate".
>
> Ok, after my patches you will be able to teach GCC about this definition
> of truncate.
I expect
> Date: Sat, 14 Mar 2009 13:07:04 +0100
> From: Paolo Bonzini
> Hans-Peter Nilsson wrote:
> >> Date: Fri, 13 Mar 2009 12:34:49 +0100
> >> From: Paolo Bonzini
> >
> >> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> >> (which define SHIFT_COUNT_TRUNCATED as 0) and for mco
2009/3/13 Paolo Bonzini :
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact.
Hans-Peter Nilsson wrote:
>> Date: Fri, 13 Mar 2009 12:34:49 +0100
>> From: Paolo Bonzini
>
>> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
>> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
>> do not define it at all) it is right that shift counts a
On Fri, 13 Mar 2009, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
On Fri, Mar 13, 2009 at 6:06 PM, Paolo Bonzini wrote:
>
> So, I'd still need the information for arm and m68k, because that
> information is about the bitfield instructions.
For ARM, shifts by immediate use a 5-bit constant, shifts by register
use the lower 8 bits of the register.
For ARMv6T2/AR
> Date: Fri, 13 Mar 2009 12:34:49 +0100
> From: Paolo Bonzini
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
The answer
On Fri, 13 Mar 2009, Richard Guenther wrote:
> Last time I sent a patch to remove the SHIFT_COUNT_TRUNCATED check
> from fold-const.c the reason that this was rejected was that we want to
> be consistend with target behavior...
I would disagree with such a rejection. If we want to provide any so
Paolo Bonzini writes:
> In addition, for arm and m68k I'd like to know whether bitfield
> instructions truncate the bit position the same as shifts (8 bits for
> arm, 6 bits for m68k).
For the m68k bitfield insns (when operating on memory) the bit position
can be in the full range of a signed 32
On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
wrote:
> On Fri, 13 Mar 2009, Richard Guenther wrote:
>
>> Hm. In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts. Thus, Paolo, I think
>> what fold-const.c does is what we should assu
On Fri, 13 Mar 2009, Richard Guenther wrote:
> Hm. In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts. Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED. No?
I think attempting the s
> Note, one thing I encountered when doing the SSE5 work at AMD, is
> SHIFT_COUNT_TRUNCATED really needs a mode argument (and ideally should be
> moved
> into the gcc_target structure).
In fact I'm reusing the TARGET_SHIFT_TRUNCATION_MASK element that is
already there and accepts a mode.
Paolo
> "Paolo" == Paolo Bonzini writes:
Paolo> These are all the !SHIFT_COUNT_TRUNCATED targets. For 4.5 I
Paolo> would like to improve our RTL canonicalization so that no
Paolo> out-of-range shifts are ever in the RTL representation.
Paolo> This in turn means that the description given by
On Mar 13, 2009, at 10:06 AM, Paolo Bonzini wrote:
Hm. In fold-const.c we try to make sure to produce the same result
as the target would for constant-folding shifts. Thus, Paolo, I
think
what fold-const.c does is what we should assume for
!SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is
>>> Hm. In fold-const.c we try to make sure to produce the same result
>>> as the target would for constant-folding shifts. Thus, Paolo, I think
>>> what fold-const.c does is what we should assume for
>>> !SHIFT_COUNT_TRUNCATED. No?
>> Unfortunately it is not so simple. fold-const.c is actuall
On Fri, Mar 13, 2009 at 12:34:49PM +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by
Paolo Bonzini wrote:
> So you have that in the RTL stream we should canonicalize "a << 32" to
> "a", but "a << (b & 31)" is not the same as "a << b"?
Yes when the msb of b is set.
> Also, how is the sign bit is significant? Does it determine whether the
> value is left- or right-shifted?
Yep
On Fri, Mar 13, 2009 at 4:07 PM, Paolo Bonzini wrote:
>
>> Hm. In fold-const.c we try to make sure to produce the same result
>> as the target would for constant-folding shifts. Thus, Paolo, I think
>> what fold-const.c does is what we should assume for
>> !SHIFT_COUNT_TRUNCATED. No?
>
> Unfort
> Hm. In fold-const.c we try to make sure to produce the same result
> as the target would for constant-folding shifts. Thus, Paolo, I think
> what fold-const.c does is what we should assume for
> !SHIFT_COUNT_TRUNCATED. No?
Unfortunately it is not so simple. fold-const.c is actually wrong, a
On Fri, Mar 13, 2009 at 2:14 PM, Bernd Schmidt wrote:
> Paolo Bonzini wrote:
>> These are all the !SHIFT_COUNT_TRUNCATED targets.
>>
>> For 4.5 I would like to improve our RTL canonicalization so that no
>> out-of-range shifts are ever in the RTL representation.
>>
>> This in turn means that the d
> /* Immediate shift counts are truncated by the output routines (or was it
>the assembler?). Shift counts in a register are truncated by SH. Note
>that the native compiler puts too large (> 32) immediate shift counts
>into a register and shifts by the register, letting the SH decide
On Fri, 2009-03-13 at 12:34 +0100, Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_
> The Blackfin does not truncate shift counts. The documentation
> specifies that e.g. for "Dx >>= Dy" instructions, shift counts greater
> than 31 produce a result of zero. Other shift instructions use a sign
> extended part of the shift count to shift either left or right. "I
> don't know" is
Ian Lance Taylor wrote:
> Paolo Bonzini writes:
>
>> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
>> must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
>> I want it to mean "it is never truncated".
>
> You need to do more work to make that happen, as
Paolo Bonzini wrote:
> These are all the !SHIFT_COUNT_TRUNCATED targets.
>
> For 4.5 I would like to improve our RTL canonicalization so that no
> out-of-range shifts are ever in the RTL representation.
>
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. R
Paolo Bonzini writes:
> This in turn means that the description given by SHIFT_COUNT_TRUNCATED
> must be exact. Right now !SHIFT_COUNT_TRUNCATED means "I don't know",
> I want it to mean "it is never truncated".
You need to do more work to make that happen, as SHIFT_COUNT_TRUNCATED
applies to b
Paolo Bonzini wrote:
> I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
> (which define SHIFT_COUNT_TRUNCATED as 0) and for mcore,sh,vax (which
> do not define it at all) it is right that shift counts are never
> truncated.
sh defines SHIFT_COUNT_TRUNCATED according to target
These are all the !SHIFT_COUNT_TRUNCATED targets.
For 4.5 I would like to improve our RTL canonicalization so that no
out-of-range shifts are ever in the RTL representation.
This in turn means that the description given by SHIFT_COUNT_TRUNCATED
must be exact. Right now !SHIFT_COUNT_TRUNCATED mea
32 matches
Mail list logo
