From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
 by sourceware.org (Postfix) with ESMTP id 507933858D35
 for <gcc-help@gcc.gnu.org>; Mon, 20 Apr 2020 15:47:18 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 507933858D35
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=kernel.crashing.org
Authentication-Results: sourceware.org;
 spf=fail smtp.mailfrom=segher@kernel.crashing.org
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])
 by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 03KFlHRC002110;
 Mon, 20 Apr 2020 10:47:17 -0500
Received: (from segher@localhost)
 by gate.crashing.org (8.14.1/8.14.1/Submit) id 03KFlHsF002107;
 Mon, 20 Apr 2020 10:47:17 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to
 segher@kernel.crashing.org using -f
Date: Mon, 20 Apr 2020 10:47:17 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: William Tambe <tambewilliam@gmail.com>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: prevent zero-extension when using a memory load instruction
Message-ID: <20200420154717.GR26902@gate.crashing.org>
References: <CAF8i9mO=nwW4fdQS_rmOGxWm-XueM67R1DMFJ3z5vyjsOQNT+Q@mail.gmail.com>
 <20200420095041.GP26902@gate.crashing.org>
 <CAF8i9mOJ9sHs=B6apvR8+Mc=xwT03dKNpw+dD6HdLLmak9Ex1Q@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAF8i9mOJ9sHs=B6apvR8+Mc=xwT03dKNpw+dD6HdLLmak9Ex1Q@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-11.7 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL,
 KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR,
 T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-help@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-help mailing list <gcc-help.gcc.gnu.org>
List-Unsubscribe: <http://gcc.gnu.org/mailman/options/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-request@gcc.gnu.org?subject=help>
List-Subscribe: <http://gcc.gnu.org/mailman/listinfo/gcc-help>,
 <mailto:gcc-help-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Apr 2020 15:47:19 -0000

Hi!

On Mon, Apr 20, 2020 at 10:36:35AM -0400, William Tambe via Gcc-help wrote:
> > > In the machine description file, is there a way to tell GCC that a
> > > memory load instruction already zero-extend such that it does not try
> > > to apply zero-extension ?
> >
> > At least on a load-store architecture (like a usual RISC), you get best
> > results if you make a separate pattern for that, and then let combine
> > combine the zero_extend with the load.
> 
> I tried creating zero_extend pattern that could move data from memory
> to a register (aka memory load), however GCC never used it and
> preferred using memory load followed by a zero-extend.

Use -dap and look at the dump files; see what happened?  You often get
it done by expand already (which isn't such a great idea, but hey), but
some cases are done by combine as well.  If you get separate load and
extend insns generated, you can look at the combine dump to see why
those insns didn't combine there.


Segher