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
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion
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
t
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
gcc/
* tree-ssa-math-opts.c (convert_plusminus_to_widen): Permit a single
conversion statement separating multipl
On Mon, Jul 11, 2011 at 6:55 PM, 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_mad
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 conversi
On Fri, Jul 8, 2011 at 2:44 PM, Andrew Stubbs 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, short b,
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 Thu, Jul 7, 2011 at 2:28 PM, Richard Guenther
wrote:
> On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs 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
On Thu, Jul 7, 2011 at 1:43 PM, Andrew Stubbs 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 to consi
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 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.
+/* Ch
On Mon, Jul 4, 2011 at 4:23 PM, Andrew Stubbs wrote:
> 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
>
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
b
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'
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
> multiply-
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'r
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,
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 un
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 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 h
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 s
On Fri, Jul 1, 2011 at 1:58 PM, Stubbs, Andrew 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 now (using mul
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, th
Hi,
On Tue, 28 Jun 2011, Andrew Stubbs 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
On 28/06/11 16:53, Michael Matz wrote:
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 s
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 d
On Tue, Jun 28, 2011 at 12:47 PM, Andrew Stubbs 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 this p
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.
I
On Fri, Jun 24, 2011 at 6:58 PM, Stubbs, Andrew
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, I'll go away and do that t
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
On Fri, Jun 24, 2011 at 3:46 PM, Stubbs, Andrew
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 sure?
Yes, def
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 10:05 AM, Andrew Stubbs
wrote:
> On 23/06/11 17:26, Richard Guenther wrote:
>>
>> On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs
>> wrote:
>>>
>>> There are many cases where the widening_mult pass does not recognise
>>> widening multiply-and-accumulate cases simply because
On 23/06/11 17:26, Richard Guenther wrote:
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs 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.
T
On 06/23/2011 07:40 AM, Andrew Stubbs wrote:
+++ b/gcc/testsuite/gcc.target/arm/umlal-1.c
+/* { dg-final { scan-assembler "umlal" } } */
Don't use the name of the instruction as the test name or the scan
will always pass, because the file name shows up in assembly output.
See http://gcc.gnu.org/
On Thu, Jun 23, 2011 at 4:40 PM, Andrew Stubbs 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 rectify that simply
37 matches
Mail list logo
