On Wed, Oct 30, 2013 at 9:02 PM, Cong Hou co...@google.com 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
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 ubiz...@gmail.com wrote:
On Wed, Oct 30, 2013 at 9:02 PM, Cong Hou co...@google.com wrote:
I have run check_GNU_style.sh
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou co...@google.com 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
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 @@
Forget to attach the patch file.
thanks,
Cong
On Wed, Oct 30, 2013 at 10:01 AM, Cong Hou co...@google.com 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
On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou co...@google.com 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
On Wed, Oct 30, 2013 at 10:22 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Wed, Oct 30, 2013 at 6:01 PM, Cong Hou co...@google.com 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
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 ubiz...@gmail.com wrote:
On Wed, Oct 30, 2013 at
On Wed, Oct 30, 2013 at 7:01 PM, Cong Hou co...@google.com 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
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 ubiz...@gmail.com wrote:
On Wed, Oct 30, 2013 at 7:01 PM, Cong Hou co...@google.com wrote:
I found my problem:
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
On Tue, Oct 29, 2013 at 1:38 AM, Uros Bizjak ubiz...@gmail.com 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
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou co...@google.com 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
On Tue, Oct 29, 2013 at 10:34 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou co...@google.com 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
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
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
jos...@codesourcery.com 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
On Wed, Oct 23, 2013 at 11:18 PM, Jakub Jelinek ja...@redhat.com 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
jos...@codesourcery.com wrote:
On Tue, 22 Oct 2013, Cong Hou wrote:
For abs(char/short), type conversions are
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
On Wed, Oct 23, 2013 at 5:11 AM, pins...@gmail.com wrote:
Sent from my iPad
On Oct 22, 2013, at 7:23 PM, Cong Hou co...@google.com 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
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 ((int)
On Wed, Oct 23, 2013 at 5:52 PM, Joseph S. Myers
jos...@codesourcery.com 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
On Tue, Oct 22, 2013 at 8:11 PM, pins...@gmail.com wrote:
Sent from my iPad
On Oct 22, 2013, at 7:23 PM, Cong Hou co...@google.com 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
On Wed, Oct 23, 2013 at 12:20 AM, Uros Bizjak ubiz...@gmail.com 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
On Wed, Oct 23, 2013 at 8:52 AM, Joseph S. Myers
jos...@codesourcery.com 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
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
Sent from my iPad
On Oct 22, 2013, at 7:23 PM, Cong Hou co...@google.com 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.
26 matches
Mail list logo
