On Mar 13, 2009, Paolo Bonzini bonz...@gnu.org 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
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_TRUNCATED. No?
On 3/14/09, Paolo Bonzini bonz...@gnu.org 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
Martin Guy wrote:
On 3/14/09, Paolo Bonzini bonz...@gnu.org 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
On 3/16/09, Paolo Bonzini bonz...@gnu.org 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
Date: Sat, 14 Mar 2009 13:07:04 +0100
From: Paolo Bonzini bonz...@gnu.org
Hans-Peter Nilsson wrote:
Date: Fri, 13 Mar 2009 12:34:49 +0100
From: Paolo Bonzini bonz...@gnu.org
I would like to know whether for avr,bfin,cris,frv,h8300,pdp11,rs6000
(which define SHIFT_COUNT_TRUNCATED as
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
must
Hans-Peter Nilsson wrote:
Date: Fri, 13 Mar 2009 12:34:49 +0100
From: Paolo Bonzini bonz...@gnu.org
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
2009/3/13 Paolo Bonzini bonz...@gnu.org:
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
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
Paolo Bonzini bonz...@gnu.org 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
Paolo Bonzini bonz...@gnu.org 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
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. Right
Ian Lance Taylor wrote:
Paolo Bonzini bonz...@gnu.org 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,
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 probably
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
/* 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 what
On Fri, Mar 13, 2009 at 2:14 PM, Bernd Schmidt bernds_...@t-online.de 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
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, as
On Fri, Mar 13, 2009 at 4:07 PM, Paolo Bonzini bonz...@gnu.org 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?
Paolo Bonzini bonz...@gnu.org 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 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
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, as
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
Paolo == Paolo Bonzini bonz...@gnu.org 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
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
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 same
On Fri, Mar 13, 2009 at 7:07 PM, Joseph S. Myers
jos...@codesourcery.com 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
Paolo Bonzini bonz...@gnu.org 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
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 sort
Date: Fri, 13 Mar 2009 12:34:49 +0100
From: Paolo Bonzini bonz...@gnu.org
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.
On Fri, Mar 13, 2009 at 6:06 PM, Paolo Bonzini bonz...@gnu.org 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.
32 matches
Mail list logo
