From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17441 invoked by alias); 15 Mar 2004 23:20:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17393 invoked from network); 15 Mar 2004 23:20:37 -0000 Received: from unknown (HELO frothingslosh.sfbay.redhat.com) (66.187.237.200) by sources.redhat.com with SMTP; 15 Mar 2004 23:20:37 -0000 Received: from frothingslosh.sfbay.redhat.com (localhost.localdomain [127.0.0.1]) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10) with ESMTP id i2FNKUIS005139; Mon, 15 Mar 2004 15:20:30 -0800 Received: (from rth@localhost) by frothingslosh.sfbay.redhat.com (8.12.10/8.12.10/Submit) id i2FNKUqe005137; Mon, 15 Mar 2004 15:20:30 -0800 X-Authentication-Warning: frothingslosh.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Mon, 15 Mar 2004 23:20:00 -0000 From: Richard Henderson To: Devang Patel Cc: "gcc@gcc.gnu.org list" Subject: Re: [lno] [RFC] if-conversion and auto vectorizer Message-ID: <20040315232029.GB5053@redhat.com> Mail-Followup-To: Richard Henderson , Devang Patel , "gcc@gcc.gnu.org list" References: <7F249017-7628-11D8-A9FC-003065FC08E4@spies.com> <20040315223807.GA4850@redhat.com> <74CCC879-76D5-11D8-B445-000393A91CAA@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <74CCC879-76D5-11D8-B445-000393A91CAA@apple.com> User-Agent: Mutt/1.4.1i X-SW-Source: 2004-03/txt/msg00754.txt.bz2 On Mon, Mar 15, 2004 at 03:06:56PM -0800, Devang Patel wrote: > We keep using term SELECT because that's what we used in our discussion > earlier. But now SELECT means MODIFY_EXPR >. Ok, thanks. > Concerns we have is: Do we need separate pass (which I am currently > implementing) to transform if-then-else to use 'conditional modify > expr' for vectorizer or not? I suspect that your vectorizer will want something much stronger than what we will ever get from phiopts. Phiopts is simply trying to tidy up simple situations. -- Something that you should watch is that COND_EXPR is *not* predication, and you can't force it to be predication on most targets. Depending on what papers you're reading, this may significantly affect what you're planning on doing. The big distinction involves trapping expressions and operands. E.g. if (test) T_1 = *p; else T_2 = 0; T_3 = PHI (T_1, T_2); cannot be transformed to T_1 = *p; T_3 = test ? T_1 : 0; unless you can show either that (1) dereferencing *p will never trap, or (2) some other dereference of *p dominates this test. Similar examples can be shown with arithmetic such as divide, or fp arithmetic without -ffast-math (i.e. when we can't discount NaNs). r~