From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-390267-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22971 invoked by alias); 29 Apr 2012 08:43:07 -0000
Received: (qmail 22959 invoked by uid 22791); 29 Apr 2012 08:43:06 -0000
X-SWARE-Spam-Status: No, hits=-4.3 required=5.0	tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED
X-Spam-Check-By: sourceware.org
Received: from localhost (HELO gcc.gnu.org) (127.0.0.1)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Apr 2012 08:42:54 +0000
From: "marc.glisse at normalesup dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/53100] Optimize __int128 with range information
Date: Sun, 29 Apr 2012 08:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: marc.glisse at normalesup dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields:
Message-ID: <bug-53100-4-EaMTetEMN9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53100-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53100-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2012-04/txt/msg02549.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100

--- Comment #2 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-29 08:42:36 UTC ---
(In reply to comment #1)
> On the other hand, tree-vrp does have the information that the
> differences are in [-4294967295, 4294967295], which comfortably fits in a type
> half the size of __int128. It seems a possible strategy would be to have
> tree-vrp mark variables that fit in a type half their size (only for TImode?),
> try and preserve that information along the way, and finally use it in
> expand_doubleword_mult.

An other possibility would be, when the range analysis detects this situation,
to have it introduce a double-cast: (__int128)(long)var. In the example here,
it would give:

((__int128)(long)((__int128)c-(__int128)a))*((__int128)(long)((__int128)f-(__int128)b))

and existing optimizations already handle:

(long)((__int128)c-(__int128)a) as (long)c-(long)a

and

(__int128)mylong1*(__int128)mylong2 as a widening multiplication.

But then we'd have to be careful not to introduce too many such casts, not to
introduce them too late, and not to introduce them just before an optimization
that removes them. And find the appropriate half-sized type to cast to. And
possibly do this only for modes not handled natively.