This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Convincing the optimizer (another fun bit of code) to optmize?

I'm a bit curious as to why this bit of code wasn't AS optimized as it would normally be. I have written compilers, so I am not clueless it's just strange the optimizer didn't optimize out some of this code.
This code becomes

  ADCON1 = chan->constants.location_info.con1 & 0x70;
  ADMUX = chan->constants.location_info.mux;
  ADCON0 = chan->constants.type_info.con0;
  OCH = chan->a2d.och;
  OCM = chan->a2d.ocm;
  OCL = chan->a2d.ocl;

  GCH = chan->a2d.gch;
  GCM = chan->a2d.gcm;
  GCL = chan->a2d.gcl;

this code

0010         L?0038:
0010         L?0039:
0010 F582              MOV     DPL,A
0012 E4                CLR     A
0013 3E                ADDC    A,R6
0014 F583              MOV     DPH,A
0016 E0                MOVX    A,@DPTR
0017 22                RET

0000 8F82              MOV     DPL,R7
0002 8E83              MOV     DPH,R6
0004 A3                INC     DPTR
0005 A3                INC     DPTR
0006 E0                MOVX    A,@DPTR
0007 5470              ANL     A,#070H
0009 F5DD              MOV     ADCON1,A
                                           ; SOURCE LINE # 279
000B 8F82              MOV     DPL,R7
000D 8E83              MOV     DPH,R6
000F E0                MOVX    A,@DPTR
0010 F5D7              MOV     ADMUX,A
                                           ; SOURCE LINE # 282
0012 EF                MOV     A,R7
0013 2404              ADD     A,#04H
0015 120000      R     LCALL   L?0038
0018 F5DC              MOV     ADCON0,A
                                           ; SOURCE LINE # 286
001A EF                MOV     A,R7
001B 2417              ADD     A,#017H
001D 120000      R     LCALL   L?0038
0020 F5D3              MOV     OCH,A
                                           ; SOURCE LINE # 287
0022 EF                MOV     A,R7
0023 2418              ADD     A,#018H
0025 120000      R     LCALL   L?0039
0028 F5D2              MOV     OCM,A
                                           ; SOURCE LINE # 288
002A EF                MOV     A,R7
002B 2419              ADD     A,#019H
002D 120000      R     LCALL   L?0039
0030 F5D1              MOV     OCL,A
                                           ; SOURCE LINE # 290
0032 EF                MOV     A,R7
0033 241A              ADD     A,#01AH
0035 120000      R     LCALL   L?0039
0038 F5D6              MOV     GCH,A
                                           ; SOURCE LINE # 291
003A EF                MOV     A,R7
003B 241B              ADD     A,#01BH
003D 120000      R     LCALL   L?0039
0040 F5D5              MOV     GCM,A
                                           ; SOURCE LINE # 292
0042 EF                MOV     A,R7
0043 241C              ADD     A,#01CH
0045 120000      R     LCALL   L?0039
0048 F5D4              MOV     GCL,A


First all the information is references from a pointer.
All variable data access is sequential from said pointer. Why isn't it optimizing out the ADD A, #XXX into INC DPTR?
It has done this a number of other places in the code. Why not here?

Do I have the settings wrong or something?
Do I need to arrange the code differently?

This is embedded into an ISR could that be the reason (that wouldn't make sense however ... )

If anyone can let me know if I need to do something different.

Stephen

Parents
  • More interesting code checking. This really shows more
    what is going on. The code really is very simple and
    straight forward and yet ...

    Compiler settings:

    OPTIMIZE (9,SIZE) BROWSE NOINTPROMOTE INCDIR(.\headers)
     DEBUG OBJECTEXTEND CODE LISTINCLUDE SYMBOLS
     PRINT(.\object\list_map\*.lst) TABS (3)
    


    C Code

    void    print_hex4(uint8_t xdata *      dat)
    {
            print_hex(*dat++);
            //dat++;
            print_hex(*dat++);
            //dat++;
            print_hex(*dat++);
            //dat++;
            print_hex(*dat);
    }
    

    Output Listing

                 ; FUNCTION _print_hex4 (BEGIN)
                                               ; SOURCE LINE # 175
    0000 8E00        R     MOV     dat,R6
    0002 8F00        R     MOV     dat+01H,R7
                                               ; SOURCE LINE # 176
                                               ; SOURCE LINE # 177
    0004 0500        R     INC     dat+01H
    0006 E500        R     MOV     A,dat+01H
    0008 7002              JNZ     ?C0051
    000A 0500        R     INC     dat
    000C         ?C0051:
    000C 120000      R     LCALL   L?0058
                                               ; SOURCE LINE # 179
    000F 0500        R     INC     dat+01H
    0011 E500        R     MOV     A,dat+01H
    0013 AE00        R     MOV     R6,dat
    0015 7002              JNZ     ?C0052
    0017 0500        R     INC     dat
    0019         ?C0052:
    0019 120000      R     LCALL   L?0058
                                               ; SOURCE LINE # 181
    001C 0500        R     INC     dat+01H
    001E E500        R     MOV     A,dat+01H
    0020 AE00        R     MOV     R6,dat
    0022 7002              JNZ     ?C0053
    0024 0500        R     INC     dat
    0026         ?C0053:
    0026 14                DEC     A
    0027 F582              MOV     DPL,A
    0029 8E83              MOV     DPH,R6
    002B E0                MOVX    A,@DPTR
    002C FF                MOV     R7,A
    002D 120000      R     LCALL   _print_hex
                                               ; SOURCE LINE # 183
    0030 850082      R     MOV     DPL,dat+01H
    0033 850083      R     MOV     DPH,dat
    0036 E0                MOVX    A,@DPTR
    0037 FF                MOV     R7,A
    0038 020000      R     LJMP    _print_hex
                                               ; SOURCE LINE # 184
    003B         L?0058:
    003B 14                DEC     A
    003C F582              MOV     DPL,A
    003E 8E83              MOV     DPH,R6
    0040 E0                MOVX    A,@DPTR
    0041 FF                MOV     R7,A
    0042 120000      R     LCALL   _print_hex
    0045 22                RET
                 ; FUNCTION _print_hex4 (END)
    


    This is rather .. interesting I suspect it may be the
    difference of how optimizers behavior between STATIC
    and pointer analysis. The pointer analysis appears to
    be the place where things aren't as optimized (although
    it might not be that easy to transform the code in
    simplification passes to 'optimal').

    Stephen

Reply
  • More interesting code checking. This really shows more
    what is going on. The code really is very simple and
    straight forward and yet ...

    Compiler settings:

    OPTIMIZE (9,SIZE) BROWSE NOINTPROMOTE INCDIR(.\headers)
     DEBUG OBJECTEXTEND CODE LISTINCLUDE SYMBOLS
     PRINT(.\object\list_map\*.lst) TABS (3)
    


    C Code

    void    print_hex4(uint8_t xdata *      dat)
    {
            print_hex(*dat++);
            //dat++;
            print_hex(*dat++);
            //dat++;
            print_hex(*dat++);
            //dat++;
            print_hex(*dat);
    }
    

    Output Listing

                 ; FUNCTION _print_hex4 (BEGIN)
                                               ; SOURCE LINE # 175
    0000 8E00        R     MOV     dat,R6
    0002 8F00        R     MOV     dat+01H,R7
                                               ; SOURCE LINE # 176
                                               ; SOURCE LINE # 177
    0004 0500        R     INC     dat+01H
    0006 E500        R     MOV     A,dat+01H
    0008 7002              JNZ     ?C0051
    000A 0500        R     INC     dat
    000C         ?C0051:
    000C 120000      R     LCALL   L?0058
                                               ; SOURCE LINE # 179
    000F 0500        R     INC     dat+01H
    0011 E500        R     MOV     A,dat+01H
    0013 AE00        R     MOV     R6,dat
    0015 7002              JNZ     ?C0052
    0017 0500        R     INC     dat
    0019         ?C0052:
    0019 120000      R     LCALL   L?0058
                                               ; SOURCE LINE # 181
    001C 0500        R     INC     dat+01H
    001E E500        R     MOV     A,dat+01H
    0020 AE00        R     MOV     R6,dat
    0022 7002              JNZ     ?C0053
    0024 0500        R     INC     dat
    0026         ?C0053:
    0026 14                DEC     A
    0027 F582              MOV     DPL,A
    0029 8E83              MOV     DPH,R6
    002B E0                MOVX    A,@DPTR
    002C FF                MOV     R7,A
    002D 120000      R     LCALL   _print_hex
                                               ; SOURCE LINE # 183
    0030 850082      R     MOV     DPL,dat+01H
    0033 850083      R     MOV     DPH,dat
    0036 E0                MOVX    A,@DPTR
    0037 FF                MOV     R7,A
    0038 020000      R     LJMP    _print_hex
                                               ; SOURCE LINE # 184
    003B         L?0058:
    003B 14                DEC     A
    003C F582              MOV     DPL,A
    003E 8E83              MOV     DPH,R6
    0040 E0                MOVX    A,@DPTR
    0041 FF                MOV     R7,A
    0042 120000      R     LCALL   _print_hex
    0045 22                RET
                 ; FUNCTION _print_hex4 (END)
    


    This is rather .. interesting I suspect it may be the
    difference of how optimizers behavior between STATIC
    and pointer analysis. The pointer analysis appears to
    be the place where things aren't as optimized (although
    it might not be that easy to transform the code in
    simplification passes to 'optimal').

    Stephen

Children
No data