IF statement Optimization in codewarrior 5.1 version

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

IF statement Optimization in codewarrior 5.1 version

Jump to solution
2,876 Views
ashushetty
Contributor I
hi ,
 
i have problem with the optimization in an IF loop.
 
The code is as follows:
#define mDeviceJoinReqClusterID  0x1201
#define mDataClusterId_c      0x1200         
 
 
  if (abc ==TRUE) // not necessary abc is always true , it is global variable.
  
  {
            
   afAddrInfo.aClusterId[0] = (mDeviceJoinReqClusterID & 0xFF);
afAddrInfo.aClusterId[1] = ( mDeviceJoinReqClusterID>> 8);      
  }                                                                
    
  else {
   
  afAddrInfo.aClusterId[0] = (mDataClusterId_c & 0xFF);
  afAddrInfo.aClusterId[1] = (mDataClusterId_c >> 8);
  }
 
in the above if loop , it considers both as same part , i think the warning is C5912 .
and when i generate a list file and check it out i see that there is no code generated only for the second line of IF loop, i.e. afAddrInfo.aClusterId[1] = ( mDeviceJoinReqClusterID>> 8); where in all other lines will have code.
 
and in both loops i m suppose to get different values since both are using different MACRO values.
 
 
 
and also i place that second line as first , then code works fine. i meant no optimization.
how do i avoid it ? do i need to disable any optimization, and i want the code in same format.
 
Labels (1)
Tags (1)
0 Kudos
1 Solution
701 Views
CompilerGuru
NXP Employee
NXP Employee
Hmm. If you actually get the information C5912, than it sounds like a bug.
When I tried to reproduce it (see the code below) that message was not issued.
Note that the compiler is only emmiting the code for the second assingment to afAddrInfo.aClusterId[1]  once as that is actually assigning the same value in both conditions.

So is the problem you observe that the second line gets merged, or is it that both conditions do get folded?

The condition folding would be a bug, please could you provide a complete compilable sample of the actual code, best with a listing file so we see the output.

If the problem is "just" the optimization of the merged second line, then use the options
"-onb=t -onbt -onf"
The first two are disabling two levels of branch tail merging, the third one (-onf, common code) is was also collecting the identical code once the branch tail merging was disabled.

Daniel


Here's the code I tried to reproduce the issue:

struct {
  unsigned char aClusterId[2];
} afAddrInfo;

#define TRUE 1
int abc;
void test(void) {
  /* put your own code here */
#define mDeviceJoinReqClusterID  0x1201
#define mDataClusterId_c      0x1200        

  if (abc == TRUE) {
    afAddrInfo.aClusterId[0] = (mDeviceJoinReqClusterID & 0xFF);
    afAddrInfo.aClusterId[1] = (mDeviceJoinReqClusterID>> 8);     
  } else {
    afAddrInfo.aClusterId[0] = (mDataClusterId_c & 0xFF);
    afAddrInfo.aClusterId[1] = (mDataClusterId_c >> 8);
  }
}


This code did generate the following code which looks correct, as far as I see. (The code is optimized, without the options to disable the branch tail merging).

   13:    if (abc == TRUE) {
  0000 c60001   [4]             LDA   abc:1
  0003 4b08     [3]             DBNZA LD ;abs = 000d
  0005 c60000   [4]             LDA   abc
  0008 2603     [3]             BNE   LD ;abs = 000d
   14:      afAddrInfo.aClusterId[0] = (mDeviceJoinReqClusterID & 0xFF);
  000a a601     [2]             LDA   #1
   15:      afAddrInfo.aClusterId[1] = (mDeviceJoinReqClusterID>> 8);     
   16:    } else {
  000c 21       [3]             SKIP1 LE ;abs = 000e
  000d          LD:    
   17:      afAddrInfo.aClusterId[0] = (mDataClusterId_c & 0xFF);
  000d 4f       [1]             CLRA 
  000e          LE:    
  000e c70000   [4]             STA   afAddrInfo
   18:      afAddrInfo.aClusterId[1] = (mDataClusterId_c >> 8);
  0011 a612     [2]             LDA   #18
  0013 c70001   [4]             STA   afAddrInfo:1
   19:    }
   20:  }
  0016 81       [4]             RTS  
   21: 

View solution in original post

0 Kudos
3 Replies
702 Views
CompilerGuru
NXP Employee
NXP Employee
Hmm. If you actually get the information C5912, than it sounds like a bug.
When I tried to reproduce it (see the code below) that message was not issued.
Note that the compiler is only emmiting the code for the second assingment to afAddrInfo.aClusterId[1]  once as that is actually assigning the same value in both conditions.

So is the problem you observe that the second line gets merged, or is it that both conditions do get folded?

The condition folding would be a bug, please could you provide a complete compilable sample of the actual code, best with a listing file so we see the output.

If the problem is "just" the optimization of the merged second line, then use the options
"-onb=t -onbt -onf"
The first two are disabling two levels of branch tail merging, the third one (-onf, common code) is was also collecting the identical code once the branch tail merging was disabled.

Daniel


Here's the code I tried to reproduce the issue:

struct {
  unsigned char aClusterId[2];
} afAddrInfo;

#define TRUE 1
int abc;
void test(void) {
  /* put your own code here */
#define mDeviceJoinReqClusterID  0x1201
#define mDataClusterId_c      0x1200        

  if (abc == TRUE) {
    afAddrInfo.aClusterId[0] = (mDeviceJoinReqClusterID & 0xFF);
    afAddrInfo.aClusterId[1] = (mDeviceJoinReqClusterID>> 8);     
  } else {
    afAddrInfo.aClusterId[0] = (mDataClusterId_c & 0xFF);
    afAddrInfo.aClusterId[1] = (mDataClusterId_c >> 8);
  }
}


This code did generate the following code which looks correct, as far as I see. (The code is optimized, without the options to disable the branch tail merging).

   13:    if (abc == TRUE) {
  0000 c60001   [4]             LDA   abc:1
  0003 4b08     [3]             DBNZA LD ;abs = 000d
  0005 c60000   [4]             LDA   abc
  0008 2603     [3]             BNE   LD ;abs = 000d
   14:      afAddrInfo.aClusterId[0] = (mDeviceJoinReqClusterID & 0xFF);
  000a a601     [2]             LDA   #1
   15:      afAddrInfo.aClusterId[1] = (mDeviceJoinReqClusterID>> 8);     
   16:    } else {
  000c 21       [3]             SKIP1 LE ;abs = 000e
  000d          LD:    
   17:      afAddrInfo.aClusterId[0] = (mDataClusterId_c & 0xFF);
  000d 4f       [1]             CLRA 
  000e          LE:    
  000e c70000   [4]             STA   afAddrInfo
   18:      afAddrInfo.aClusterId[1] = (mDataClusterId_c >> 8);
  0011 a612     [2]             LDA   #18
  0013 c70001   [4]             STA   afAddrInfo:1
   19:    }
   20:  }
  0016 81       [4]             RTS  
   21: 

0 Kudos
701 Views
ashushetty
Contributor I
Hi daniel,
 
It works now fine. It was problem with optimization .
 
Those warnings were coming only if i was creating a seperate workspace  tht C5912.
Now it works fine.
 
One more thing is if i disable the " branch tail " and tht "ICG " it is working fine , no need of third option.
i.e. " -OnB=t -Onbt  '
But third option is it very necessary>?when my code is working fine.
 
pls let me know on this too.
 
thanks for a quick reply!
 
regards
ashwini
0 Kudos
701 Views
CompilerGuru
NXP Employee
NXP Employee
I'm not sure given your description if this is a debug display issue, of if the issue is incorrect code being created.
Without "-OnB=t -Onbt ", does the afAddrInfo.aClusterId variable contain a wrong value after executing the code?

Anyway, if you don't need -onf, then don't specify it :smileyhappy:. It does avoid the common code optimization which can create unexpected shared code, and it did trigger for the snippet I compiled.

Daniel
0 Kudos