linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
To: linux-sparse@vger.kernel.org
Cc: Christopher Li <sparse@chrisli.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Subject: [RFC] CSE: relax type checking in hashing/compare
Date: Fri, 17 Feb 2017 01:06:07 +0100	[thread overview]
Message-ID: <20170217000608.6433-1-luc.vanoostenryck@gmail.com> (raw)

Currently in a function like here below the comparision is not
optimized away. This is because CSE doesn't recognize 'a = &g'
and 'b = &g' as being equivalent expressions.
	static int foo(void) {
		extern int g;
		void *a = &g;
		void *b = &g;
		return a == b;
	}

The problem come in fact from the implicit cast, more precisely, 
because the two '&g' generate their own symbol and thus have
distinct types.

I made a patch (see the second one in this non-serie) so that
cast from equivalent types hash identically. It worked well
but after a while I concluded that it was not really needed.
Indeed, in the context of CSE, to consider two instructions as
equivalent, the first thing that need to be equal is their source
operands. Isn't it already the case that if we use the same pseudo
in two instructions, the type of these pseudo in each instructions
must already be, if not identical, at least 'sufficently equivalent'?

I'm missing something?

If not, then the following simple patch should be correct.

Note: this patch give almost the same results as my original,
complex version. Both can eliminate quite a few casts (the
output of test-linearize on a subset of GCC's testsuite gives
a good 33K diff), both gives correct results for the case I've
checked and when using sparse on a kernel's allyesconfig run,
both give exactly the same warnings with ot without the patch).

Luc Van Oostenryck

---
 cse.c | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/cse.c b/cse.c
index 89812afae..d7f5de302 100644
--- a/cse.c
+++ b/cse.c
@@ -91,13 +91,6 @@ static void clean_up_one_instruction(struct basic_block *bb, struct instruction
 	case OP_CAST:
 	case OP_SCAST:
 	case OP_PTRCAST:
-		/*
-		 * This is crap! Many "orig_types" are the
-		 * same as far as casts go, we should generate
-		 * some kind of "type hash" that is identical
-		 * for identical casts
-		 */
-		hash += hashval(insn->orig_type);
 		hash += hashval(insn->src);
 		break;
 
@@ -235,11 +228,6 @@ static int insn_compare(const void *_i1, const void *_i2)
 	case OP_CAST:
 	case OP_SCAST:
 	case OP_PTRCAST:
-		/*
-		 * This is crap! See the comments on hashing.
-		 */
-		if (i1->orig_type != i2->orig_type)
-			return i1->orig_type < i2->orig_type ? -1 : 1;
 		if (i1->src != i2->src)
 			return i1->src < i2->src ? -1 : 1;
 		break;

             reply	other threads:[~2017-02-17  0:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-17  0:06 Luc Van Oostenryck [this message]
2017-02-17  0:06 ` [RFC,original PATCH] CSE: let equivalent cast hash & compare identically Luc Van Oostenryck
2017-02-27  8:09 ` [RFC] CSE: relax type checking in hashing/compare Christopher Li
2017-02-27  8:11 ` Christopher Li
2017-02-27  9:40   ` Luc Van Oostenryck
2017-04-19  0:32     ` Christopher Li
2017-04-19 16:32       ` Luc Van Oostenryck

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=20170217000608.6433-1-luc.vanoostenryck@gmail.com \
    --to=luc.vanoostenryck@gmail.com \
    --cc=linux-sparse@vger.kernel.org \
    --cc=sparse@chrisli.org \
    --cc=torvalds@linux-foundation.org \
    /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 NNTP newsgroup(s).