• Wrong code gerated by icc compiler

    From Mike B.@21:1/5 to All on Sat Jan 16 05:30:12 2021
    Hi

    A short note about an ugly bug in icc (or I'm unable to catch the point).

    I'm writing code to program a controller on a T2 TRAM which is mapped to address 0x10.

    #define MODE_REG 2
    #define MORE_REG 3

    #define CONTROLLER ((unsigned int volatile *)0x10)

    int test1( unsigned int val ) {

    unsigned int volatile *Controller = CONTROLLER;

    Controller[ MODE_REG ] = val;
    Controller[ MORE_REG ] = val;
    }

    This generates the following code:

    ldl 3 -- val
    ldl 0 -- Controller
    stnl 2

    ldl 3 -- val
    ldl 0 -- Controller
    stnl 3

    Later I recognized that this local variable is not really required and ldl also takes 2 cycles, so I changed the code to:

    #define CONTROLLER(r) (((unsigned int volatile *)(0x10))[r])

    int test2( unsigned int val ) {

    CONTROLLER( MODE_REG ) = val;
    CONTROLLER( MORE_REG ) = val;
    }

    /*

    This generates the following code:

    ldl 2 -- val
    ldc 20
    stnl 0

    ldl 2 -- val
    ldc 22
    stnl 0

    Unfortunately, the code is 1 byte longer (for each controller access) as ldl 20 requires a prefix.
    I don't understand why icc did not generate the more direct variant:

    ldl 2 -- val
    ldc 16
    stnl 2

    To get rid of the pfix I changed the code again to:

    #define CONTROLLER(r) (((unsigned int volatile *)(0x00))[r+8])

    int test3( unsigned int val ) {

    CONTROLLER( MODE_REG ) = val;
    CONTROLLER( MORE_REG ) = val;
    }

    My hope was the following desired code:

    ldl 2 -- val
    ldc 0
    stnl 10

    BUT that's what icc is generating:

    ldl 2 -- val
    mint
    stnl 10

    ldl 2 -- val
    mint
    stnl 11

    We are overwriting values below memstart!

    This happens with:

    icc 2.01.10
    icc 2.02.29
    icc 4.01.13

    icc 3.01.41 is not able to generate code for T2 but optimizes test3 to the same code as test2.

    Generating suboptimal code is frustrating but generating wrong code is unforgivable.
    As this will be unfixed for the future, keep always an eye on the generated assembler code if things don't work as expected.

    -Mike

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mike B.@21:1/5 to All on Mon Jan 18 03:36:01 2021
    Fortunately this is 16bit specific only.

    -Mike

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)