On 02/06/11 10:46, Richard Earnshaw wrote:
OK.
Committed, thanks.
Andrew
On Thu, 2011-05-26 at 14:35 +0100, Andrew Stubbs wrote:
> On 25/05/11 14:47, Joseph S. Myers wrote:
> > The shift must be by a positive constant amount, strictly less than the
> > precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
> > If that applies, the relevant number of b
On Thu, 26 May 2011, Andrew Stubbs wrote:
> On 25/05/11 14:47, Joseph S. Myers wrote:
> > The shift must be by a positive constant amount, strictly less than the
> > precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
> > If that applies, the relevant number of bits is the pre
On 25/05/11 14:47, Joseph S. Myers wrote:
The shift must be by a positive constant amount, strictly less than the
precision (GET_MODE_PRECISION) of the mode (of the value being shifted).
If that applies, the relevant number of bits is the precision of the mode
minus the number of bits of the shif
On Wed, 25 May 2011, Andrew Stubbs wrote:
> On 25/05/11 14:19, Joseph S. Myers wrote:
> > RTL has defined abstract semantics and RTL transformations should be ones
> > that are valid in accordance with those semantics, with proper assertions
> > if there are additional constraints on the input pas
On 25/05/11 14:19, Joseph S. Myers wrote:
RTL has defined abstract semantics and RTL transformations should be ones
that are valid in accordance with those semantics, with proper assertions
if there are additional constraints on the input passed to a function.
This means actually counting the num
On Wed, 25 May 2011, Andrew Stubbs wrote:
> I know that, potentially, not all shifted operands are going to be widening
> multiplies, but I *think* this should be safe because other random shift
> values are unlikely to match a real widening mult instruction (and if they do
> then the code would a
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplified and
superfluous extends remo
On Wed, 25 May 2011, Andrew Stubbs wrote:
> So, you're saying that promoting a regular multiply to a widening multiply
> isn't a valid transformation anyway? I suppose that does make sense. I knew
In general, yes. RTL always has modulo semantics (except for division and
remainder by -1); all op
On 24/05/11 20:35, Joseph S. Myers wrote:
On Tue, 24 May 2011, Andrew Stubbs wrote:
I've created this new, simpler patch that converts
(extend (mult a b))
into
(mult (extend a) (extend b))
regardless of what 'a' and 'b' might be. (These are then simplified and
superfluous extends remo
On Tue, 24 May 2011, Andrew Stubbs wrote:
> I've created this new, simpler patch that converts
>
> (extend (mult a b))
>
> into
>
> (mult (extend a) (extend b))
>
> regardless of what 'a' and 'b' might be. (These are then simplified and
> superfluous extends removed, of course.)
Are there
On 03/05/11 10:07, Bernd Schmidt wrote:
I tried to fix it with the patch below, which unfortunately doesn't work
since during combine we don't see the SIGN_EXTEND operations inside the
MULT, but two shift operations instead. Maybe you can complete it from here?
I've tried to make this patch go
12 matches
Mail list logo
