ICC compiler inefficiencies

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After two months of using AVR tools including ICE200 and ICEPRO with AVR Studio and the ImageCraft compiler, I am both greatly satisfied with their capabilities and hopeful for future developments in the compiler. The following inefficiencies in particular surprised me:
1. Case statements that do not take into account the type nor possible range of the switch parameter. With a switch parameter of unsigned char, the case processing treats it as a signed word. It takes many cases before it is more efficient than if..else if..else construction.
2. There is no provision for 8x8=16 and 16x16=32 multiplies. This means that extra casting is required in the source and longer processing time than necessary.
3. Expression evaluation that occurs multiple times is repeated. A simple construct like
func(parm){} that includes the expression -parm more than once recalculates -parm every time.
I'm sure that others have observed similar problems. I would apreciate comments or other examples.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A lot of this is down to the language definition. A few years back I drew certain compiler authors attention to a type promotion “bug”. Even quoted the appropriate part of the ‘C’ language specification to them. It turned out that the ANSI committee had since changed it, and so I was wrong! Personally I think a the ANSI committee made a few duff decisions, or at least they didn’t take minimal resource applications very much into account.

So don’t shoot the ‘C’ implementor until you determine that he’s not been following a necessary ANSI stipulation.

Your point 3 is called sub-expression elimination, and should be part of any decent optimizer. Are you sure the upmarket version of ImageCraft doesn’t handle this?

Terry

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dave, please feel free to email me directly to continue with this. I'm very interested in your opinions etc. Specifically to answer your questions:
1) case value optimizations. Noted. I will need to think about how best to use the information.
2) 8x8=16,16x16=32. The problem is that there is no portable C way of expressing that. We can of course provide library functions for you to call directly. I will add that to the enhancement bin.
3) Common Subexpressions. Currently, we do eliminate CS in a straight block of code, but not across basic blocks. THat will be coming this Summer in our PRO version with classical optimizations.

// richard

Richard Man http://imagecraft.com

Beyond Arduino - When you're ready to get serious...
JumpStart C Tools, The Better Alternative.