EmbeddedRelated.com
Forums

A compiler optimization puzzle

Started by ratishpunnoose March 1, 2011
Hi,
I'm using version 5.20.2 (5.20.2.50216) which is the latest version with all patches.
Here are the other settings:

Device: MSP430F1611, normal DLIB,
Optimization: High (for speed), all optimizations enabled.

I also found that it is the loop unrolling optimization
that may be causing the problem. Disabling that fixes it.

Ratish

--- In m..., "david_mcminn" wrote:
> [snip]
>
> I tried your original code and the refactored code using IAR (compiler version 5.10.1.50144) and I could never get it to generate the assembly with the call to puts() removed.
>
> This was using a realease build, fully optimised for size with a normal DLIB, for an F149. What project settings did you have?
>

Beginning Microcontrollers with the MSP430

UPDATE:
I had reported a compiler bug to IAR after this thread conversation in
March
(http://tech.groups.yahoo.com/group/msp430/message/47777
)
IAR's update this week to version 5.30.1 of the compiler fixed it.

Thanks to all who responded.
Ratish

--- In m..., "Paul Curtis" wrote:
>
> Hi,
>
> > People from IAR are reading here too. They should be able to verify
> > your problem. I do not use IAR, so I can not...
> >
> > I still in doubt that this is a compiler fault - because the fault
you
> > are reporting would hurt anybody else using the IAR. "while (P1IN);"
or
> > similar is a very common use of sfr's. Maybe it is a problem with
the
> > compiler setup.
>
> I think this is a bug, and I believe there is a release note for the
IAR
> compiler that shows that this is fixed.
>
> Using data flow the compiler is able to prove that the while is not
iterated
> if P1IN is zero:
>
> Original:
>
> static int log_calls(int num_iters)
> {
> puts("\nlogging");
> return (num_iters-1);
> }
>
> void myfunc(void)
> {
> signed int remaining_calls = 1;
>
> while (P1IN == 0 && (remaining_calls = log_calls(remaining_calls)) >
0)
> ;
> }
>
> We know that the first call is log_calls(1) by data flow analysis and
that
> log_calls will return zero by data flow analysis and as a side-effect
will
> print something.
>
> Hence, this can be transformed from what we know to:
>
> void myfunc(void)
> {
> if (P1IN == 0)
> puts("\nlogging");
> (void)P1IN; // as P1IN volatile and requires testing in the while
> }
>
> That is the effect of this function. No more, no less.
>
> The question is now what "puts" does. If it's
>
> void puts(const char *) {}
>
> Then the IAR compiler is correct. However, from the description of
this and
> the analysis the OP has done and provided, it smells like a compiler
issue.
>
> -- Paul.
>



On 14 July 2011 20:33, Ratish Punnoose wrote:
> UPDATE:
> I had reported a compiler bug to IAR after this thread conversation in
> March
> (http://tech.groups.yahoo.com/group/msp430/message/47777
> )
> IAR's update this week to version 5.30.1 of the compiler fixed it.

So, is there any idea what was wrong and how was it fixed?

--
I appear to be temporarily using gmail's horrible interface. I
apologise for any failure in my part in trying to make it do the right
thing with post formatting.
--- In m..., Harri Haataja wrote:
>>On 14 July 2011 20:33, Ratish Punnoose wrote:
>> UPDATE:
>> I had reported a compiler bug to IAR after this thread conversation in
>> March
>> (http://tech.groups.yahoo.com/group/msp430/message/47777
>> )
>> IAR's update this week to version 5.30.1 of the compiler fixed it.
>

> So, is there any idea what was wrong and how was it fixed?
> ------------------

This specific bug does not appear anymore. I am not sure what "general class of bugs" was eliminated. The Release Notes don't even mention anything about any bugs being fixed. I had received a private email from IAR support about a month ago that my bug report (front-line support called it a glitch) would be fixed in this release.

It would be helpful if the IAR release notes contain details of previous bugs in the compiler that now have been fixed. But they don't.

Thanks again All.
Ratish