William F Mitchell writes:
> Richard Maine wrote:
>
> > In some cases, you need parens
> > just to establish the mathematical meaning of an expression like
> > a*(b+c). You don't really care whether or not the compiler evaluates
> > it that way or expands it to a*b+a*c; whatever it finds faster is ok.
>
> I'm sure this is just a bad choice of example to make a good point, but this is
> one of the substitutions explicitly forbidden by the standard (although the
> substitution in the other direction is allowed). It is possible for the second
> expression to overflow when the first does not, if b and c are large and of
> opposite sign.
Yes, I expressed myself poorly. You are correct that the standard
forbids this expansion. That's because it has parens in it, and the
standard doesn't allow violation of parens.
I was trying to talk about the 2 separate reasons that you would want
to use parens - not two separate ways the compiler handles them.
The compiler can't tell the difference between these two reasons,
and that's the problem.
My purpose in this para was just to focus on the user's intent instead of the
requirements of the standard. That the user might have written the
expression and not cared which way the compiler did it. But the
compiler can't read the user's mind - only the code - so it interprets
the parens in both ways - as defining the expression and as limiting
its options for optimization.
Agree its probably a bad choice of example. I just used the first
expression with parens that came to mind. Its pretty hard to imagine
a case where it would actually make sense to do a*b+a*c. Perhaps a*b
and a*c had just been used in previous lines and were still handy in
registers or something. That might do it.
--
Richard Maine
[log in to unmask]
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|