From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64764 invoked by alias); 3 Jan 2019 19:04:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 64753 invoked by uid 89); 3 Jan 2019 19:04:04 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1379, day X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 19:04:02 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5F74DEBD; Thu, 3 Jan 2019 11:04:01 -0800 (PST) Received: from localhost (unknown [10.32.98.35]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B2FB33F5D4; Thu, 3 Jan 2019 11:04:00 -0800 (PST) From: Richard Sandiford To: Alan Modra Mail-Followup-To: Alan Modra ,gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] genattrtab bit-rot, and if_then_else in values References: <20190103092154.GZ30978@bubble.grove.modra.org> <87a7khsyjz.fsf@arm.com> <20190103143637.GA3170@bubble.grove.modra.org> <87lg41r7nb.fsf@arm.com> Date: Thu, 03 Jan 2019 19:04:00 -0000 In-Reply-To: <87lg41r7nb.fsf@arm.com> (Richard Sandiford's message of "Thu, 03 Jan 2019 17:08:24 +0000") Message-ID: <87h8epr2ao.fsf@arm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2019-01/txt/msg00119.txt.bz2 Richard Sandiford writes: > Alan Modra writes: >> If the operands of PLUS are assumed to be insn lengths (reasonable, >> since you're likely to use PLUS to sum the machine insn lengths of a >> pattern that conditionally emits multiple machine insns), then it >> might be better to replace "current_or += n" above with >> "current_or |= n". That would be correct for a length expression of >> (plus (if_then_else (condA) (const_int 4) (const_int 0)) >> (if_then_else (condB) (const_int 8) (const_int 4))) >> where any answer from or_attr_value that has 3 lsbs of 100b is >> sufficently correct. If I keep "+=" then we'd get the wrong answer in >> this particular example. However "|=" is wrong if someone is playing >> games and writes a silly expression like >> (plus (const_int 1) (const_int 3)) >> since the length is always 4. >> >>> OK with the above dropped, thanks. >> >> Maybe this instead? >> >> case PLUS: >> current_or = or_attr_value (XEXP (exp, 0)); >> current_or |= or_attr_value (XEXP (exp, 1)); >> break; > > This still seems risky and isn't what the name and function comment > imply. Maybe we should replace or_attr_value with something like > floor_log2_attr_value or attr_value_alignment? Er, forget floor_log2_attr_value :-) First day back, etc. etc.