On 12/07/11 11:52, Richard Guenther wrote:
Is this one ok?
Ok.
I've just committed this slightly modified patch.
The changes are mainly in the context and the testcase.
Andrew
2011-08-19 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen):
On 19/07/11 00:33, Janis Johnson wrote:
On 07/14/2011 07:16 AM, Andrew Stubbs wrote:
{ dg-options -O2 -march=armv7-a }
The tests use { dg-options -O2 -march=armv7-a } but -march will be
overridden for multilibs that specify -march, and might conflict with
other multilib options. If you
On 07/14/2011 07:16 AM, Andrew Stubbs wrote:
{ dg-options -O2 -march=armv7-a }
The tests use { dg-options -O2 -march=armv7-a } but -march will be
overridden for multilibs that specify -march, and might conflict with
other multilib options. If you really need that particular -march value
then
This update changes only the context modified by changes to patch 2. The
patch has already been approved. I'm just posting it for completeness.
Andrew
2011-07-14 Andrew Stubbs a...@codesourcery.com
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion
On Mon, Jul 11, 2011 at 6:55 PM, Andrew Stubbs a...@codesourcery.com wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings,
(int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings, (int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Ok, here's my new patch.
This version only allows one
On 07/07/11 13:37, Richard Guenther wrote:
I'll cook up a quick patch for VRP.
Like the attached. I'll finish and properly test it.
Your patch appears to do the wrong thing for this test case:
int
foo (int a, short b, short c)
{
int bc = b * c;
return a + (short)bc;
}
With your patch,
On Fri, Jul 8, 2011 at 2:44 PM, Andrew Stubbs a...@codesourcery.com wrote:
On 07/07/11 13:37, Richard Guenther wrote:
I'll cook up a quick patch for VRP.
Like the attached. I'll finish and properly test it.
Your patch appears to do the wrong thing for this test case:
int
foo (int a,
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings, (int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so sure. I'll look into it a bit further.
+/*
On 07/07/11 11:26, Andrew Stubbs wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings,
(int)(short)char_variable
are already combined. Thus I believe you only need to consider a single
conversion in valid_types_for_madd_p.
Hmm, I'm not so sure.
On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs andrew.stu...@gmail.com wrote:
On 07/07/11 11:26, Andrew Stubbs wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of widenings,
(int)(short)char_variable
are already combined. Thus I believe you only need
On Thu, Jul 7, 2011 at 2:28 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs andrew.stu...@gmail.com wrote:
On 07/07/11 11:26, Andrew Stubbs wrote:
On 07/07/11 10:58, Richard Guenther wrote:
I think you should assume that series of
On 01/07/11 13:25, Richard Guenther wrote:
Well - some operations work the same on both signedness if you
just care about the twos-complement result. This includes
multiplication (but not for example division). For this special
case I suggest to not bother trying to invent a generic predicate
On 28/06/11 17:37, Michael Matz wrote:
What I want (and I'm not totally clear on what this actually means) is
to be able to optimize all the cases where the end result will be the
same as the compiler produces now (using multiple multiply, shift, and
add operations).
Okay, then you
On Fri, Jul 1, 2011 at 1:58 PM, Stubbs, Andrew andrew_stu...@mentor.com wrote:
On 28/06/11 17:37, Michael Matz wrote:
What I want (and I'm not totally clear on what this actually means) is
to be able to optimize all the cases where the end result will be the
same as the compiler produces
On 07/01/2011 01:58 PM, Stubbs, Andrew wrote:
Given this test case:
unsigned long long
foo (unsigned long long a, signed char *b, signed char *c)
{
return a + *b * *c;
}
Those rules say that it should not be suitable for optimization because
there's an implicit cast from
On 01/07/11 13:33, Paolo Bonzini wrote:
Got it now! Casts from signed to unsigned are not value-preserving, but
they are bit-preserving: s32-s64 obviously is, and s32-u64 has the
same result bit-by-bit as the s64 result. The fact that s64 has an
implicit ... in front, while an u64 has an
On 07/01/2011 03:30 PM, Stubbs, Andrew wrote:
However, perhaps there is a catch. We can do the following thought
experiment. What would happen if you had multiple widening multiplies?
Like 8-bit signed to 64-bit unsigned and then 64-bit unsigned to 128-bit
unsigned? I believe in this
On 01/07/11 15:40, Paolo Bonzini wrote:
On 07/01/2011 03:30 PM, Stubbs, Andrew wrote:
However, perhaps there is a catch. We can do the following thought
experiment. What would happen if you had multiple widening multiplies?
Like 8-bit signed to 64-bit unsigned and then 64-bit unsigned to
On 01/07/11 14:30, Stubbs, Andrew wrote:
Got it now! Casts from signed to unsigned are not value-preserving, but
they are bit-preserving: s32-s64 obviously is, and s32-u64 has the
same result bit-by-bit as the s64 result. The fact that s64 has an
implicit ... in front, while an u64
On 07/01/2011 04:55 PM, Stubbs, Andrew wrote:
What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to
(u128)c + (u128)((s8)a * (s8)b).
Oh I see, sorry. Yes, that's exactly what I'm trying to do here.
No, wait, I don't see. Where are these multiple widening multiplies
you're
On 06/28/11 18:14, Andrew Stubbs wrote:
unsigned long long
foo (unsigned long long a, unsigned char b, unsigned char c)
{
return a + b * c;
}
This appears to be entirely unsigned maths with plenty of spare
precision, and therefore a dead cert for any SI-DI
On 01/07/11 16:54, Paolo Bonzini wrote:
On 07/01/2011 04:55 PM, Stubbs, Andrew wrote:
What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to
(u128)c + (u128)((s8)a * (s8)b).
Oh I see, sorry. Yes, that's exactly what I'm trying to do here.
No, wait, I don't see. Where are
On 24/06/11 16:47, Richard Guenther wrote:
I can certainly add checks to make sure that the skipped operations
actually don't make any important changes to the value, but do I need to?
Yes.
OK, how about this patch?
I've added checks to make sure the value is not truncated at any point.
On Tue, Jun 28, 2011 at 12:47 PM, Andrew Stubbs andrew.stu...@gmail.com wrote:
On 24/06/11 16:47, Richard Guenther wrote:
I can certainly add checks to make sure that the skipped operations
actually don't make any important changes to the value, but do I need
to?
Yes.
OK, how about
Hi,
On Tue, 28 Jun 2011, Richard Guenther wrote:
I'd name the predicate value_preserving_conversion_p which I think is
what you mean. harmless isn't really descriptive.
Note that you include non-value-preserving conversions, namely int -
unsigned int.
It seems that Andrew really does
On 23/06/11 17:26, Richard Guenther wrote:
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbsandrew.stu...@linaro.org wrote:
There are many cases where the widening_mult pass does not recognise
widening multiply-and-accumulate cases simply because there is a type
conversion step between the
On Fri, Jun 24, 2011 at 10:05 AM, Andrew Stubbs
andrew.stu...@linaro.org wrote:
On 23/06/11 17:26, Richard Guenther wrote:
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbsandrew.stu...@linaro.org
wrote:
There are many cases where the widening_mult pass does not recognise
widening
On 24/06/11 09:28, Richard Guenther wrote:
To be clear, it only skips past NOP_EXPR. Is it not the case that what
you're describing would need a CONVERT_EXPR?
NOP_EXPR is the same as CONVERT_EXPR.
Are you sure?
I thought this was safe because the internals manual says:
NOP_EXPR
On Fri, Jun 24, 2011 at 3:46 PM, Stubbs, Andrew
andrew_stu...@mentor.com wrote:
On 24/06/11 09:28, Richard Guenther wrote:
To be clear, it only skips past NOP_EXPR. Is it not the case that what
you're describing would need a CONVERT_EXPR?
NOP_EXPR is the same as CONVERT_EXPR.
Are you
On 24/06/11 16:47, Richard Guenther wrote:
I can certainly add checks to make sure that the skipped operations
actually don't make any important changes to the value, but do I need to?
Yes.
Ok, I'll go away and do that then.
BTW, I see useless_type_conversion_p, but that's not quite what
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs andrew.stu...@linaro.org wrote:
There are many cases where the widening_mult pass does not recognise
widening multiply-and-accumulate cases simply because there is a type
conversion step between the multiply and add statements.
This patch should
32 matches
Mail list logo
