Ian Lance Taylor wrote on 01/18/07 10:51:
Well, internally, we do have ASSERT_EXPR. It would probably take a
little work to permit the frontends to generate it, but the optimizers
should understand it.
By default, they do not. When I initially implemented VRP, I was adding
ASSERT_EXPRs right after gimplification. The rationale was to have the
ASSERT_EXPRs rewritten into SSA form by the initial SSA pass. This was
convenient, but it destroyed the quality of generated code. Suddenly,
little or no copies, constants were being propagated, jump threading
wasn't working, PRE wasn't doing its job, etc.
The problem was that all these ASSERT_EXPRs were not being grokked by
the optimizers, every optimizer would see the assertion, think the worst
and block transformations.
It also meant quite a bit of bulk added to the IL which increased
compilation times. So, if we decide to add ASSERT_EXPRs early in the
pipeline, we have to mind these issues.
In the end, I went for adding assertions inside VRP and fixing up the
SSA form incrementally. Perhaps we can do something similar for other
passes that may want to deal with assertions.
Now, if these are assertions inserted by the user, that's another
problem. The IL wouldn't bulk up so much, but we would still need to
handle them everywhere. Assertions shouldn't block scalar cleanups.
