public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Ilya Enkovich <enkovich.gnu@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Use signed boolean type for boolean vectors
Date: Mon, 09 Nov 2015 14:04:00 -0000	[thread overview]
Message-ID: <20151109140327.GC51763@msticlxl57.ims.intel.com> (raw)
In-Reply-To: <CAFiYyc0ArEPrms2cmGMPZ0OiVZSz77GKL7fNPwCAs621ye3j6A@mail.gmail.com>

On 03 Nov 14:42, Richard Biener wrote:
> On Wed, Oct 28, 2015 at 4:30 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> > 2015-10-28 18:21 GMT+03:00 Richard Biener <richard.guenther@gmail.com>:
> >> On Wed, Oct 28, 2015 at 2:13 PM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> >>> Hi,
> >>>
> >>> Testing boolean vector conversions I found several runtime regressions
> >>> and investigation showed it's due to incorrect conversion caused by
> >>> unsigned boolean type.  When boolean vector is represented as an
> >>> integer vector on target it's a signed integer actually.  Unsigned
> >>> boolean type was chosen due to possible single bit values, but for
> >>> multiple bit values it causes wrong casting.  The easiest way to fix
> >>> it is to use signed boolean value.  The following patch does this and
> >>> fixes my problems with conversion.  Bootstrapped and tested on
> >>> x86_64-unknown-linux-gnu.  Is it OK?
> >>
> >> Hmm.  Actually formally the "boolean" vectors were always 0 or -1
> >> (all bits set).  That is also true for a signed boolean with precision 1
> >> but with higher precision what makes sure to sign-extend 'true'?
> >>
> >> So it's far from an obvious change, esp as you don't change the
> >> precision == 1 case.  [I still think we should have precision == 1
> >> for all boolean types]
> >>
> >> Richard.
> >>
> >
> > For 1 bit precision signed type value 1 is out of range, right? This might break
> > in many place due to used 1 as true value.
> 
> For vectors -1 is true.  Did you try whether it breaks many places?
> build_int_cst (type, 1) should still work fine.
> 
> Richard.
> 

I tried it and didn't find any new failures.  So looks I was wrong assuming it should cause many failures.  Testing is not complete because many SPEC benchmarks are failing to compile on -O3 for AVX-512 on trunk.  But I think we may proceed with signed type and fix constant generation issues if any revealed.  This patch was bootstrapped and regtested on x86_64-unknown-linux-gnu.  OK for trunk?

Thanks,
Ilya
--
gcc/

2015-11-09  Ilya Enkovich  <enkovich.gnu@gmail.com>

	* optabs.c (expand_vec_cond_expr): Always get sign from type.
	* tree.c (wide_int_to_tree): Support negative values for boolean.
	(build_nonstandard_boolean_type): Use signed type for booleans.


diff --git a/gcc/optabs.c b/gcc/optabs.c
index fdcdc6a..44971ad 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -5365,7 +5365,6 @@ expand_vec_cond_expr (tree vec_cond_type, tree op0, tree op1, tree op2,
       op0a = TREE_OPERAND (op0, 0);
       op0b = TREE_OPERAND (op0, 1);
       tcode = TREE_CODE (op0);
-      unsignedp = TYPE_UNSIGNED (TREE_TYPE (op0a));
     }
   else
     {
@@ -5374,9 +5373,9 @@ expand_vec_cond_expr (tree vec_cond_type, tree op0, tree op1, tree op2,
       op0a = op0;
       op0b = build_zero_cst (TREE_TYPE (op0));
       tcode = LT_EXPR;
-      unsignedp = false;
     }
   cmp_op_mode = TYPE_MODE (TREE_TYPE (op0a));
+  unsignedp = TYPE_UNSIGNED (TREE_TYPE (op0a));
 
 
   gcc_assert (GET_MODE_SIZE (mode) == GET_MODE_SIZE (cmp_op_mode)
diff --git a/gcc/tree.c b/gcc/tree.c
index 18d6544..6fb4c09 100644
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -1437,7 +1437,7 @@ wide_int_to_tree (tree type, const wide_int_ref &pcst)
 	case BOOLEAN_TYPE:
 	  /* Cache false or true.  */
 	  limit = 2;
-	  if (hwi < 2)
+	  if (IN_RANGE (hwi, 0, 1))
 	    ix = hwi;
 	  break;
 
@@ -8069,7 +8069,7 @@ build_nonstandard_boolean_type (unsigned HOST_WIDE_INT precision)
 
   type = make_node (BOOLEAN_TYPE);
   TYPE_PRECISION (type) = precision;
-  fixup_unsigned_type (type);
+  fixup_signed_type (type);
 
   if (precision <= MAX_INT_CACHED_PREC)
     nonstandard_boolean_type_cache[precision] = type;

  reply	other threads:[~2015-11-09 14:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-28 13:33 Ilya Enkovich
2015-10-28 15:24 ` Richard Biener
2015-10-28 15:31   ` Ilya Enkovich
2015-11-03 13:42     ` Richard Biener
2015-11-09 14:04       ` Ilya Enkovich [this message]
2015-11-09 14:27         ` Richard Biener

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151109140327.GC51763@msticlxl57.ims.intel.com \
    --to=enkovich.gnu@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).