This update makes it more safe. You showed me how to write better
expand code. Thank you for the improvement!
thanks,
Cong
On Thu, Oct 31, 2013 at 11:43 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 9:02 PM, Cong Hou wrote:
>> I have run check_GNU_style.sh on my patch.
>>
>> The patch is
On Wed, Oct 30, 2013 at 9:02 PM, Cong Hou wrote:
> I have run check_GNU_style.sh on my patch.
>
> The patch is submitted. Thank you for your comments and help on this patch!
I have committed a couple of fixes/improvements to your expander in
i386.c. There is no need to check for the result of
exp
I have run check_GNU_style.sh on my patch.
The patch is submitted. Thank you for your comments and help on this patch!
thanks,
Cong
On Wed, Oct 30, 2013 at 11:13 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 7:01 PM, Cong Hou wrote:
>
I found my problem: I put DONE outside of if not
On Wed, Oct 30, 2013 at 7:01 PM, Cong Hou wrote:
>>> I found my problem: I put DONE outside of if not inside. You are
>>> right. I have updated my patch.
>>
>> OK, great that we put things in order ;)
>>
>> Does this patch need some extra middle-end functionality? I was not
>> able to vectorize c
Also, as the current expand for abs() on 8/16bit integer is not used
at all, should I comment them temporarily now? Later I can uncomment
them once I finished the pattern recognizer.
thanks,
Cong
On Wed, Oct 30, 2013 at 10:22 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou
On Wed, Oct 30, 2013 at 10:22 AM, Uros Bizjak wrote:
> On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou wrote:
>> I found my problem: I put DONE outside of if not inside. You are
>> right. I have updated my patch.
>
> OK, great that we put things in order ;)
>
> Does this patch need some extra middle-en
On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou wrote:
> I found my problem: I put DONE outside of if not inside. You are
> right. I have updated my patch.
OK, great that we put things in order ;)
Does this patch need some extra middle-end functionality? I was not
able to vectorize char and short part
Forget to attach the patch file.
thanks,
Cong
On Wed, Oct 30, 2013 at 10:01 AM, Cong Hou wrote:
> I found my problem: I put DONE outside of if not inside. You are
> right. I have updated my patch.
>
> I appreciate your comment and test on it!
>
>
> thanks,
> Cong
>
>
>
> diff --git a/gcc/Chan
I found my problem: I put DONE outside of if not inside. You are
right. I have updated my patch.
I appreciate your comment and test on it!
thanks,
Cong
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 8a38316..84c7ab5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2013-10-22
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>>> For the define_expand I added as below, the else body is there to
>>> avoid fall-through transformations to ABS operation in optabs.c.
>>> Otherwise ABS will be converted to other operations even that we have
>>> corresponding instructions from
On Tue, Oct 29, 2013 at 10:34 AM, Uros Bizjak wrote:
> On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>
For the define_expand I added as below, the else body is there to
avoid fall-through transformations to ABS operation in optabs.c.
Otherwise ABS will be converted to other oper
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>>> For the define_expand I added as below, the else body is there to
>>> avoid fall-through transformations to ABS operation in optabs.c.
>>> Otherwise ABS will be converted to other operations even that we have
>>> corresponding instructions from
On Tue, Oct 29, 2013 at 1:38 AM, Uros Bizjak wrote:
> Hello!
>
>> For the define_expand I added as below, the else body is there to
>> avoid fall-through transformations to ABS operation in optabs.c.
>> Otherwise ABS will be converted to other operations even that we have
>> corresponding instruct
Hello!
> For the define_expand I added as below, the else body is there to
> avoid fall-through transformations to ABS operation in optabs.c.
> Otherwise ABS will be converted to other operations even that we have
> corresponding instructions from SSSE3.
No, it wont be.
Fallthrough will generate
As there are some issues with abs() type conversions, I removed the
related content from the patch but only kept the SSE2 support for
abs(int).
For the define_expand I added as below, the else body is there to
avoid fall-through transformations to ABS operation in optabs.c.
Otherwise ABS will be c
On Wed, Oct 23, 2013 at 11:18 PM, Jakub Jelinek wrote:
> On Wed, Oct 23, 2013 at 09:40:21PM -0700, Cong Hou wrote:
>> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
>> wrote:
>> > On Tue, 22 Oct 2013, Cong Hou wrote:
>> >
>> >> For abs(char/short), type conversions are needed as the current abs
On Wed, Oct 23, 2013 at 09:40:21PM -0700, Cong Hou wrote:
> On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
> wrote:
> > On Tue, 22 Oct 2013, Cong Hou wrote:
> >
> >> For abs(char/short), type conversions are needed as the current abs()
> >> function/operation does not accept argument of char/sho
I think I did not make it clear. If GCC defines that passing 128 to a
char value makes it the wrapping result -128, then the conversion from
(char) abs ((int) char_val) to abs (char_val) is safe if we can
guarantee abs (char(-128)) = -128 also. Then the subsequent methods
used to get abs() should a
On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
wrote:
> On Tue, 22 Oct 2013, Cong Hou wrote:
>
>> For abs(char/short), type conversions are needed as the current abs()
>> function/operation does not accept argument of char/short type.
>> Therefore when we want to get the absolute value of a char
On Wed, Oct 23, 2013 at 12:20 AM, Uros Bizjak wrote:
> Hello!
>
>> Currently GCC could not vectorize abs() operation for integers on x86
>> with only SSE2 support. For int type, the reason is that the expand on
>> abs() is not defined for vector type. This patch defines such an
>> expand so that a
On Tue, Oct 22, 2013 at 8:11 PM, wrote:
>
>
> Sent from my iPad
>
>> On Oct 22, 2013, at 7:23 PM, Cong Hou wrote:
>>
>> This patch aims at PR58762.
>>
>> Currently GCC could not vectorize abs() operation for integers on x86
>> with only SSE2 support. For int type, the reason is that the expand o
On Wed, Oct 23, 2013 at 5:52 PM, Joseph S. Myers
wrote:
> On Tue, 22 Oct 2013, Cong Hou wrote:
>
>> For abs(char/short), type conversions are needed as the current abs()
>> function/operation does not accept argument of char/short type.
>> Therefore when we want to get the absolute value of a char
On Tue, 22 Oct 2013, Cong Hou wrote:
> For abs(char/short), type conversions are needed as the current abs()
> function/operation does not accept argument of char/short type.
> Therefore when we want to get the absolute value of a char_val using
> abs (char_val), it will be converted into abs ((in
On Wed, Oct 23, 2013 at 5:11 AM, wrote:
>
>
> Sent from my iPad
>
>> On Oct 22, 2013, at 7:23 PM, Cong Hou wrote:
>>
>> This patch aims at PR58762.
>>
>> Currently GCC could not vectorize abs() operation for integers on x86
>> with only SSE2 support. For int type, the reason is that the expand o
Hello!
> Currently GCC could not vectorize abs() operation for integers on x86
> with only SSE2 support. For int type, the reason is that the expand on
> abs() is not defined for vector type. This patch defines such an
> expand so that abs(int) will be vectorized with only SSE2.
+(define_expand "
Sent from my iPad
> On Oct 22, 2013, at 7:23 PM, Cong Hou wrote:
>
> This patch aims at PR58762.
>
> Currently GCC could not vectorize abs() operation for integers on x86
> with only SSE2 support. For int type, the reason is that the expand on
> abs() is not defined for vector type. This patc
This patch aims at PR58762.
Currently GCC could not vectorize abs() operation for integers on x86
with only SSE2 support. For int type, the reason is that the expand on
abs() is not defined for vector type. This patch defines such an
expand so that abs(int) will be vectorized with only SSE2.
For
27 matches
Mail list logo
