public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Umesh Kalappa <umesh.kalappa0@gmail.com>
To: gcc@gcc.gnu.org
Cc: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
Subject: Fwd: GCC 8.1 :Store Merge pass issue (-fstore-merging).
Date: Wed, 11 Jul 2018 16:18:00 -0000	[thread overview]
Message-ID: <CAGfacvSKfzCVSnBAeoUbWa=sLcfZyUVF3fwWJwQm60J-zhH4Lw@mail.gmail.com> (raw)
In-Reply-To: <CAGfacvR+iw4QF+4V48vz0n9NEFhCYSDCj3CNAFkrcHqe+s8w9w@mail.gmail.com>

Cc'ed Kyrill.


---------- Forwarded message ---------
From: Umesh Kalappa <umesh.kalappa0@gmail.com>
Date: Wed, Jul 11, 2018, 7:37 PM
Subject: GCC 8.1 :Store Merge pass issue (-fstore-merging).
To: <gcc@gcc.gnu.org>


Hi Everyone ,

We have the below case ,where store marge pass doing the invalid
optimization (thats our observations on powerpc ) ,i.e

C case :

typedef unsigned int UINT32;

typedef union
    {
    UINT32 regVal;
    struct
        {
        UINT32 mask:1;
        UINT32 a:1;
        UINT32 :6;
        UINT32 p:1;
        UINT32 s:1;
        UINT32 :2;
        UINT32 priority:4;
        UINT32 vector:16;
        } field;
    } MPIC_IVPR;

UINT32 test(UINT32 vector)
{
        MPIC_IVPR       mpicIvpr;

        mpicIvpr.regVal = 0;
        mpicIvpr.field.vector = vector;
        mpicIvpr.field.priority = 0xe;

        return mpicIvpr.regVal;
}


  gcc -O2 -S   test.c

  ...
        lis 3,0xe           ;; mpicIvpr.field.priority = 15
        blr
  ...

the store dump as

Processing basic block <2>:
Starting new chain with statement:
mpicIvpr.regVal = 0;
The base object is:
&mpicIvpr
Recording immediate store from stmt:
mpicIvpr.field.vector = _1;
Recording immediate store from stmt:
mpicIvpr.field.priority = 14;
stmt causes chain termination:
_7 = mpicIvpr.regVal;
Attempting to coalesce 3 stores in chain.
Store 0:
bitsize:32 bitpos:0 val:
0
------------
Store 1:
bitsize:4 bitpos:12 val:
14
------------
Store 2:
bitsize:16 bitpos:16 val:
_1
------------

After writing 0 of size 32 at position 0 the merged region contains:
0 0 0 0 0 0 0 0
After writing 14 of size 4 at position 12 the merged region contains:
0 e 0 0 0 0 0 0
Coalescing successful!
Merged into 1 stores
New sequence of 1 stmts to replace old one of 2 stmts
# .MEM_6 = VDEF <.MEM_5>
MEM[(union  *)&mpicIvpr] = 917504;
Merging successful!
Volatile access terminates all chains
test (UINT32 vector)
{
  union MPIC_IVPR mpicIvpr;
  short unsigned int _1;
  UINT32 _7;

  <bb 2> [local count: 1073741825]:
  _1 = (short unsigned int) vector_4(D);
  mpicIvpr.field.vector = _1;
  MEM[(union  *)&mpicIvpr] = 917504;
  _7 = mpicIvpr.regVal;
  mpicIvpr ={v} {CLOBBER};
  return _7;

}


As noticed  from dump ,the store of  .regVal and  priority is folded
to single store ,since the rhs operand is constant in both stmts by
leaving the  above cfg and making  mpicIvpr.field.vector = _1 stmt as
dead code,hence latter DCE deletes the same ,which results with  the
incorrect asm as show above and we are in process of debugging the
store merge pass and we see that "  mpicIvpr.field.vector = _1; "
should clobber the first store "mpicIvpr.regVal = 0;" in the merge
store vector ,but its not clobbering ,by disabling the handling the
overlapping store ,the above case works , i.e
if(0)
{
 /* |---store 1---|
               |---store 2---|
         Overlapping stores.  */
      if (IN_RANGE (info->bitpos, merged_store->start,
                    merged_store->start + merged_store->width - 1))
        {
          if (info->rhs_code == INTEGER_CST
              && merged_store->stores[0]->rhs_code == INTEGER_CST)
            {
              merged_store->merge_overlapping (info);
              continue;
            }
        }

}

before we conclude on the same ,we would like to hear any comments
from community ,which helps us to resolve the issue  and by disabling
the store merge pass as expected the above case works .

Thank you. and looking for any suggestions on the same.
~Umesh

  reply	other threads:[~2018-07-11 16:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-11 14:07 Umesh Kalappa
2018-07-11 16:18 ` Umesh Kalappa [this message]
2018-07-11 16:47   ` Fwd: " Jakub Jelinek
2018-07-11 16:57     ` Umesh Kalappa
2018-07-12  7:42     ` Umesh Kalappa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGfacvSKfzCVSnBAeoUbWa=sLcfZyUVF3fwWJwQm60J-zhH4Lw@mail.gmail.com' \
    --to=umesh.kalappa0@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=kyrylo.tkachov@foss.arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).