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
26 matches
Mail list logo
