From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tambewilliam@gmail.com>
Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com
 [IPv6:2a00:1450:4864:20::12b])
 by sourceware.org (Postfix) with ESMTPS id 9E913384B104
 for <gcc-help@gcc.gnu.org>; Mon, 20 Apr 2020 14:36:48 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9E913384B104
Received: by mail-lf1-x12b.google.com with SMTP id j14so8131265lfg.9
 for <gcc-help@gcc.gnu.org>; Mon, 20 Apr 2020 07:36:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=FIPREjWwz9R7hiCYV2BxI0JGnDqMdzvV50vXOi+si08=;
 b=j1Zz25ij2sN70VddlUzPkwPfJfRGcs7rGXyt7UHOXBwdGtKMIs0BOwhfdbDT6QCVKz
 4RH3+jwQknIEuLJzUF9wKOkqQpRB0mVjYjAzB5EduOgntvaUprDHPGojAPS/F8q94NBi
 mamA+tVJLEsWRmkotpwI5e2GpvVOjl7XFVXh3cnqdVtwbIqGsq/AWXICCyKPxQicg8cF
 xLlVRi12UKJSZg5OZvYrimHq2qIQ/jK80dg7YGnW7o6eUJcP5hniN6PbO6Qh4DKIyVa3
 /KE10maGGKKvgLbNKpwPIBoKEQaHU6VfdXQGoh6kyD8ObwcLLOO6QAEY6KWkiRs2WjK6
 +v7A==
X-Gm-Message-State: AGi0PuZbmWgoaRmZ6lnXwg+IAyRtFx9xp9u/l8tvdw+TGch6L0VhjM00
 G9BxlI+J9Z9wcYW60qI4Dyi/AVpJ8P+Ta4iCGS4=
X-Google-Smtp-Source: APiQypJN6113scdby6yikrab9l6FszKP8rTGXx3GsWtTKOUOBJZk9Wrd5XdkJ8p2ZLujG0CD0zsqGCmBZOFId1UuiJ0=
X-Received: by 2002:a19:c194:: with SMTP id r142mr11073893lff.7.1587393407435; 
 Mon, 20 Apr 2020 07:36:47 -0700 (PDT)
MIME-Version: 1.0
References: <CAF8i9mO=nwW4fdQS_rmOGxWm-XueM67R1DMFJ3z5vyjsOQNT+Q@mail.gmail.com>
 <20200420095041.GP26902@gate.crashing.org>
In-Reply-To: <20200420095041.GP26902@gate.crashing.org>
From: William Tambe <tambewilliam@gmail.com>
Date: Mon, 20 Apr 2020 10:36:35 -0400
Message-ID: <CAF8i9mOJ9sHs=B6apvR8+Mc=xwT03dKNpw+dD6HdLLmak9Ex1Q@mail.gmail.com>
Subject: Re: prevent zero-extension when using a memory load instruction
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: gcc-help <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
 SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 14:36:49 -0000

On Mon, Apr 20, 2020 at 5:50 AM Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>
> Hi!
>
> On Sat, Apr 18, 2020 at 11:12:15AM -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.

Any other suggestions ? I have been googling around with no solution in sight.

>
>
> Segher