On Wed, Feb 17, 2010 at 3:47 AM, Bernd Petrovitsch <bernd@xxxxxxxxxxxxxxxxxxx> wrote: >> >> But for this expression: >> >> a = st && st->foo && st->bar && i > 0; >> >> This optimization might be worth while. > ACK. But this example has no side effect (assuming no preprocessor > trickery, no "volatile" somewhere relevant, etc.) so it' not > "dangerous". > Above I was talking about the general case. Then we are in agreement. Sparse actually go the extra mile to make sure the expression is safe. So whenever the expression has side effects or unsafe, it set the cost of the expression prohibitively high. E.g: expand_dereference() return UNSAFE because the expression can segfault. expand_call() return SIDE_EFFECT. So if there is a bug cause the some unsafe optimization. We just just fix the bug instead of disable the optimization. It is harder to do this optimization in the linearized instructions because the linearized instruction does not have the expression boundary any more. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
