[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[luoxhu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

luoxhu at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luoxhu at gcc dot gnu.org

--- Comment #12 from luoxhu at gcc dot gnu.org ---
Fixed at least from GCC 4.9.4?
$ /opt/at8.0/bin/gcc -O3 -c -S  pr30271.c -mstrict-align
$ cat pr30271.s
        .file   "pr30271.c"
        .abiversion 2
        .section        ".toc","aw"
        .section        ".text"
        .align 2
        .p2align 4,,15
        .globl f
        .type   f, @function
f:
        extsh 9,3
        srawi 3,3,16
        add 3,9,3
        extsw 3,3
        blr
        .long 0
        .byte 0,0,0,0,0,0,0,0
        .size   f,.-f
        .ident  "GCC: (GNU) 4.9.4 20150824 (Advance-Toolchain-at8.0)
[ibm/gcc-4_9-branch, revision: 227153 merged from gcc-4_9-branch, revision
227151]"
        .section        .note.GNU-stack,"",@progbits

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |guojiufu at gcc dot gnu.org

--- Comment #13 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> (In reply to comment #9)
> > Andrew, 
> > 
> > What is your point here?
> 
> My point here is that currently we do:
>       gi->frame_related =
>         (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx);
> 
> But if we change it to be:
>       gi->frame_related =
>         (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx)
>         || (base == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]);
> 
> It would delete the store (at least in a 4.3 based compiler). 
> arg_pointer_rtx is the incoming argument space so if it is a fixed register
> it will be also frame related and we can safely delete the stores to this
> space.

https://gcc.gnu.org/pipermail/gcc-patches/2023-December/639550.html is using
this idea too.  And the 'std' in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c2 disappeared.

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jiu Fu Guo <guojiufu@gcc.gnu.org>:

https://gcc.gnu.org/g:4759383245ac97a5c83c0272f0a831f2a26ea5c1

commit r14-6674-g4759383245ac97a5c83c0272f0a831f2a26ea5c1
Author: Jiufu Guo <guojiufu@linux.ibm.com>
Date:   Tue Dec 19 13:03:06 2023 +0800

    treat argp-based mem as frame related in dse

    The issue mentioned in PR112525 would be able to be handled by
    updating dse.cc to treat arg_pointer_rtx similarly with frame_pointer_rtx.
    https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271#c10 also mentioned
    this idea.

    And arpg area may be used to pass argument to callee. So, it would
    be needed to check if call insns are using that mem.

            PR rtl-optimization/112525
            PR target/30271

    gcc/ChangeLog:

            * dse.cc (get_group_info): Add arg_pointer_rtx as frame_related.
            (check_mem_read_rtx): Add parameter to indicate if it is checking
mem
            for call insn.
            (scan_insn): Add mem checking on call usage.

    gcc/testsuite/ChangeLog:

            * gcc.target/powerpc/pr112525.c: New test.
            * gcc.target/powerpc/pr30271.c: New test.

[Bug target/30271] -mstrict-align can add an store extra for struct argument passing

[guojiufu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

Jiu Fu Guo <guojiufu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #15 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
Fix was committed.

[Bug target/30271] -mstrict-align can add an store extra for struct argument passing

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

[Bug target/30271] New: -mstrict-align can cause bad code generation for struct agrument passing

[pinskia at gcc dot gnu dot org]

Testcase:
struct a { short t, t1;};
int f(struct a b) { return b.t; }
Without -mstrict-align, we get:
.L.f:
        srawi 3,3,16
        extsw 3,3
        blr

But with we get:
.L.f:
        stw 3,48(1)
        nop
        nop
        nop
        lha 3,48(1)
        extsw 3,3
        blr


-- 
           Summary: -mstrict-align can cause bad code generation for struct
                    agrument passing
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2008-12-11 04:42 -------
So the problem with the stores here is that the base is arg_pointer_rtx which
is still a frame pointer related offset.  I think the same can be said is true
of stack_pointer_rtx too.  We only set frame_related for frame_pointer_rtx and
hard_frame_pointer_rtx but arg_pointer_rtx will become a frame pointer later
one too.  The only issue is that there might not be correct dependencies with
respect of arg_pointer_rtx.

Kenny,
  Do you agree?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[zadeck at naturalbridge dot com]

------- Comment #9 from zadeck at naturalbridge dot com  2008-12-15 15:32 -------
Andrew, 

What is your point here?

1) Is it your claim that anything that is arg_pointer_rtx related would
automatically qualify as being safe enough to remove dead stores to?

or

2) Is it your claim that if we could generalize the game proposed in comment #7
to cover the arg_pointer_rtx's also?

Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2008-12-16 02:08 -------
(In reply to comment #9)
> Andrew, 
> 
> What is your point here?

My point here is that currently we do:
      gi->frame_related =
        (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx);

But if we change it to be:
      gi->frame_related =
        (base == frame_pointer_rtx) || (base == hard_frame_pointer_rtx)
        || (base == arg_pointer_rtx && fixed_regs[ARG_POINTER_REGNUM]);

It would delete the store (at least in a 4.3 based compiler).  arg_pointer_rtx
is the incoming argument space so if it is a fixed register it will be also
frame related and we can safely delete the stores to this space.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271

[Bug target/30271] -mstrict-align can an store extra for struct agrument passing

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2008-12-29 23:51 -------
(In reply to comment #10)
Hmm, this patch bootstraps just fine on the 4.3 branch but causes miscompares
on the trunk (the 4.3 branch had checking on also when I bootstrapped it on
i386-darwin8.11).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271