From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cgen-return-2381-listarch-cgen=sources.redhat.com@sourceware.org>
Received: (qmail 7179 invoked by alias); 5 Oct 2009 18:22:56 -0000
Received: (qmail 7169 invoked by uid 22791); 5 Oct 2009 18:22:55 -0000
X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 	tests=AWL,BAYES_00,DNS_FROM_RFC_BOGUSMX
X-Spam-Check-By: sourceware.org
Received: from sebabeach.org (HELO sebabeach.org) (64.165.110.50)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Oct 2009 18:22:49 +0000
Received: from sspiff.sspiff.org (seba.sebabeach.org [10.8.159.10]) 	by sebabeach.org (Postfix) with ESMTP id 651686E3CE; 	Mon,  5 Oct 2009 11:22:48 -0700 (PDT)
Message-ID: <4ACA3977.8090708@sebabeach.org>
Date: Mon, 05 Oct 2009 18:22:00 -0000
From: Doug Evans <dje@sebabeach.org>
User-Agent: Thunderbird 2.0.0.21 (X11/20090320)
MIME-Version: 1.0
To: Joern Rennecke <joern.rennecke@embecosm.com>
CC: cgen@sourceware.org
Subject: Re: ALIAS instructions are messed up?
References: <20091003163955.51so5zjyysow04k8-nzlynne@webmail.spamcop.net>
In-Reply-To: <20091003163955.51so5zjyysow04k8-nzlynne@webmail.spamcop.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cgen-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <cgen.sourceware.org>
List-Subscribe: <mailto:cgen-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/cgen/>
List-Post: <mailto:cgen@sourceware.org>
List-Help: <mailto:cgen-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: cgen-owner@sourceware.org
X-SW-Source: 2009-q4/txt/msg00007.txt.bz2

Joern Rennecke wrote:
>> Whether to disallow alias insns entirely is a separate question. Dunno.
>> [We could still keep it for macro-insns.
>> And I realize there are a few ports that currently use it, or at 
>> least specify > it.]
>
> Currently, macro-instructions can't be used in all instances where
> it should be natural to use them.
> When you want to set a multi-ifield to a constant, you end up with
> the entire costant being added in in the bit position of each of
> constituent simple bitfields.

Let's fix this.  Do you have an example readily available?

>
> By adding an ALIAS instruction by hand, you can at least work around
> the problem by setting only simple bitfields to constants.

Good point.