From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-199109-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 34617 invoked by alias); 20 May 2019 07:36:40 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 34604 invoked by uid 89); 20 May 2019 07:36:40 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*rguenth, tc, HX-HELO:sk:mail-qk, H*c:alternative
X-HELO: mail-qk1-f195.google.com
Received: from mail-qk1-f195.google.com (HELO mail-qk1-f195.google.com) (209.85.222.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 07:36:39 +0000
Received: by mail-qk1-f195.google.com with SMTP id z6so8195761qkl.10;        Mon, 20 May 2019 00:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:from:date:message-id:subject:to:cc;        bh=MJbkOTapz9gjnSTk8xfMmRz/B4dB/+mGncEDQzbwgng=;        b=O9d80nM9ETEvmCCMyVqrOyEamAdohyVJ36sThU6ELEVcCu7dE97yTcDOmuQsw3hPj+         hNnOXmuBsxFjyc3h7l0t99PfoRXAy0kx3k0rabMw9HVXjxJkoUFeYakfbWf8HINHbGJ6         UU/lAqxvSvl/BJwBS2KlyC/IV6F+V4ETBC/eiYHlmwVCgfGKEBG9laeHpmYHoh6EqL9T         nufwUKNq85hHhs40mYpNb6gUX5wVOeYU0g02SBcwa9hVdSt6LufNJ+JfNDcF5gLfIyag         ZOoPHQfYph6BYewklMwZLU9obpvIgm498PV1o/mjJ6j8H/m+G/59nKCwiTAllCBXMoNr         HrQw==
MIME-Version: 1.0
From: navya deepika Garakapati <navyadeepika.garakapati@gmail.com>
Date: Mon, 20 May 2019 07:36:00 -0000
Message-ID: <CAF4caZ3r1ouUEtTB-sb6X88vZsOdpWLSK6HFfqB0LCgxwLLaJg@mail.gmail.com>
Subject: Regarding Bug 85539 - x86_64: loads are not always narrowed [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85539]
To: rguenth@gcc.gnu.org, gcc@gcc.gnu.org
Cc: tilkax@gmail.com
Content-Type: text/plain; charset="UTF-8"
X-SW-Source: 2019-05/txt/msg00154.txt.bz2

Hi All,



I am looking https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85539 bug and did
some analysis.

please help me on the below query.


For the  below testcase,

$cat test.c



int foo(long *p)

{

return *p;

}



when compile with clang -O2

$clang test.c -O2 -S

$cat test.s

foo:

        movl    (%rdi), %eax

        retq



while gcc gives



$gcc test.c -O2 -S

$cat test.s

foo:

        movq    (%rdi), %rax

        retq



As you can see the difference clang is loading value in eax(32 bit) while
gcc uses rax(64 bit).


While analysing it we found that ,



In gcc trunck with -O0 optimization,



we can notice that in ira pass, there is a conversion information from
64bit to 32bit (subreg:SI (reg:DI 82 [ _1 ]) 0)):



ira pass:

(insn 8 7 11 2 (set (reg:SI 83 [ _4 ])

        (subreg:SI (reg:DI 82 [ _1 ]) 0)) "t.c":3:8 67 {*movsi_internal}

     (expr_list:REG_DEAD (reg:DI 82 [ _1 ])

        (nil)))



while reload pass is deleting this information and assigning 32bit to 32bit
i.e; SI to SI which results this as a dead code for the next pass and as a
result this insn 8 is getting deleted in next pass which is split2 pass.



reload pass:

(insn 8 7 15 2 (set (reg:SI 0 ax [orig:83 _4 ] [83])

        (reg:SI 0 ax [orig:82 _1 ] [82])) "t.c":3:8 67 {*movsi_internal}

     (nil))



We would like to know why  conversion from DI to SI is converted to SI to
SI in reload pass (which uses any target hook).




Thanks & Regards

Navya.