From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:33462)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <edgar.iglesias@gmail.com>) id 1TE55n-000492-Sq
	for qemu-devel@nongnu.org; Tue, 18 Sep 2012 17:12:28 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <edgar.iglesias@gmail.com>) id 1TE55m-0004ca-Pa
	for qemu-devel@nongnu.org; Tue, 18 Sep 2012 17:12:27 -0400
Received: from mail-lpp01m010-f45.google.com ([209.85.215.45]:59487)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <edgar.iglesias@gmail.com>) id 1TE55m-0004cQ-II
	for qemu-devel@nongnu.org; Tue, 18 Sep 2012 17:12:26 -0400
Received: by lagz14 with SMTP id z14so197504lag.4
	for <qemu-devel@nongnu.org>; Tue, 18 Sep 2012 14:12:24 -0700 (PDT)
Date: Tue, 18 Sep 2012 23:12:14 +0200
From: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Message-ID: <20120918211214.GA29439@zapo>
References: <1347836915-14091-1-git-send-email-aurelien@aurel32.net>
	<1347836915-14091-4-git-send-email-aurelien@aurel32.net>
	<CABoDooPodswEOyWj6DdD6pgtNymkwTtmWiK0ceYy_GO6oBeeyg@mail.gmail.com>
	<CAFEAcA_zumUGiwjkC2648ZVsJZki3gDTdEcjXAomJNa6Ff0p8Q@mail.gmail.com>
	<CABoDooPb+-rzgBvQ0Qc0v6KeTEDy-5NWU6FshCvS3fVByAqPkw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABoDooPb+-rzgBvQ0Qc0v6KeTEDy-5NWU6FshCvS3fVByAqPkw@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH 3/5] target-arm: convert shl and shr
 helpers to TCG
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laurent Desnogues <laurent.desnogues@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel@nongnu.org, Aurelien Jarno <aurelien@aurel32.net>

On Mon, Sep 17, 2012 at 03:36:46PM +0200, Laurent Desnogues wrote:
> On Mon, Sep 17, 2012 at 11:43 AM, Peter Maydell
> <peter.maydell@linaro.org> wrote:
> > On 17 September 2012 10:30, Laurent Desnogues
> > <laurent.desnogues@gmail.com> wrote:
> >> On Mon, Sep 17, 2012 at 1:08 AM, Aurelien Jarno <aurelien@aurel32.net> wrote:
> >>> +#define GEN_SHIFT(name)                                \
> >>> +static void gen_##name(TCGv dest, TCGv t0, TCGv t1)    \
> >>> +{                                                      \
> >>> +    TCGv tmp1, tmp2;                                   \
> >>> +    tmp1 = tcg_temp_new_i32();                         \
> >>> +    tcg_gen_andi_i32(tmp1, t1, 0xff);                  \
> >>> +    tmp2 = tcg_temp_new_i32();                         \
> >>> +    tcg_gen_setcondi_i32(TCG_COND_GE, tmp2, tmp1, 32); \
> >>> +    tcg_gen_andi_i32(tmp1, tmp1, 0x1f);                \
> >>
> >> I don't think the 'and 0x1f' is needed given that later you'll and
> >> with 0 if the shift amount is >= 32.
> >
> > The TCG shift operations are undefined behaviour (not merely
> > undefined result) if the shift is >= 32, so we must avoid
> > doing that even if we're going to throw away the answer.
> 
> That's odd that it doesn't just state that the result is undefined.
> I wonder what "undefined behavior" means.  I understand
> what undefined behavior (as opposed tu undefined result)
> means for divisions by 0, but not for a shift larger than data
> type width.
> 
> Anyway that makes my comment about removing the & 0x1f
> pointless.

Hi,

I'm a bit late with email but I don't think your comment is
irrelevant. It sounds like if we are optimizing for very odd
or nonexisting archs. Is there any modern arch that has
undefined behaviour (in reality and not only in theoretical
specs) these days?

Cheers,
E