[Bug c/12038] New: more optimization with -Os option for arm

[Bug c/12038] New: more optimization with -Os option for arm

[vittasoft at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: more optimization with -Os option for arm
           Product: gcc
           Version: 3.3.1
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vittasoft at yahoo dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686
  GCC host triplet: i686
GCC target triplet: arm-thumb-elf

If function contains any branches (generated by if/for/do/while), compiler saves
lr register into stack. You can see it in this example:

unsigned int my(char *s){
  if(s == NULL)
     return 1;
  return 0;
};

try to compile it with -mthumb -Os -S and you will see code like this:

        .align  2
        .global my
        .thumb_func
        .type   my,function
my:
        push    {lr}         @ <------ It's because function have a branch
        cmp     r0, #0
        beq     .L11
        mov     r0, #0
.L9:
        @ sp needed for prologue
        pop     {pc}
.L11:
        mov     r0, #1
        b       .L9          
.Lfe2:
        .size   my,.Lfe2-my
@ <--- gcc-3.3.1/gcc/config/arm/arm.c:thumb_far_jump_used_p
@ always returns 1 if branch command founds.
@ in this case get_attr_far_jump (insn) always returns FAR_JUMP_YES on branch,
@ because it's check length of attribute and attribute length always equal 8

[Bug c/12038] more optimization with -Os option for arm

[vittasoft at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From vittasoft at yahoo dot com  2003-08-23 00:05 -------
Created an attachment (id=4645)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4645&action=view)
here is a patch

I don't know does thumb_far_jump_used_p used anything else except in
THUMB_INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET)

[Bug c/12038] more optimization with -Os option for arm

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pessimizes-code
   Target Milestone|3.4                         |---


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-23 02:16 -------
Your patch is only a workaround, the right thing to do is to figure out why get_attr_far_jump 
always return true.

[Bug c/12038] more optimization with -Os option for arm

[vittasoft at yahoo dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From vittasoft at yahoo dot com  2003-08-24 19:52 -------
Well... Sorry, This is my first post in gcc bugzilla.
All things are simple:
gcc/final.c:
get_attr_length for JUMP_INSN returns insn_default_length(insn), which equal to 8

gcc/insn-attrtab.c:
get_attr_far_jump for JUMP_INSN check if get_attr_length for current instruction
equal 8, returns FAR_JUMP_YES.

But in ARM no matter how far is jump. I also didn't know why authors check this.
Here doesn't used LR register anything. But it forced saves in stack.

[Bug target/12038] more optimization with -Os option for arm

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c                           |target
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-24 19:58:39
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-24 19:58 -------
Your analysis see legit (I do not use ARM that much).
Hopefully one of the ARM maintainers could tell use why thumb_far_jump_used_p always return 
true and why even look at thumb_far_jump_used_p in the first place.

[Bug target/12038] more optimization with -Os option for arm

[rearnsha at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From rearnsha at gcc dot gnu dot org  2003-09-05 11:08 -------
When compiling large functions in Thumb code the only instruction that has
sufficient range to span the entire range of the function is the BL instruction.
 But that instruction will clobber the link register.  We must therefore be
prepared to save the link register if it might be clobbered.  Unfortunately,
during reload we cannot necessarily tell how large the function will be (since
the reload instructions have not been emitted at that time).  What is more,
whether or not the link register is saved can affect elimination offsets, so we
can't change our mind later on.

The standard branch instruction has a range of approximately +/- 2048 bytes
(1024 thumb instructions).  If we worked on the assumption that reload would not
generate more than one reload on average for each instruction, then it would
probably be fairly safe to assume that any function with fewer than 512 insns
before reload would never grow beyond the 1024 addressable range afterwards. 
That would eliminate the need to save the link register for this reason in the
vast majority of leaf functions where this is a problem.

get_attr_far_jump always returns true during reload because branch shortening
has not taken place at that time.  We cannot run branch shortening until we know
how many instructions will be added by reload.  Catch 22.

[Bug target/12038] more optimization with -Os option for arm

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-21 03:49 -------
Fixed on the mainline.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |3.5.0


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