On 10/19/2017 06:50 PM, Christopher Li wrote: > On Thu, Oct 19, 2017 at 5:42 AM, Uwe Kleine-König <uwe@xxxxxxxxxxxxxxxxx> wrote: >> >> I wonder about the name. From a debug build (in contrast to a release >> build) I would expect that it allows to debug sparse itself (Think: add >> -g to gcc, or (not) -DNODEBUG for assert(3)), but I understand you use >> that term differently here. > > The name if mechanical. You can suggest better names. I am > more focus on allowing two version of sparse can be compile > at the same time. > >> >> Why not do the the extra tests when called as (say) >> >> sparse --aggressive >> > > Yes, actually that is what I have in mind. When "--aggressive" > is turn on, sparse will execute "dbg-sparse" to enable those aggressive > code path. The optional name is subject to change. > >> . Then there is no need for an extra binary at all keeping the build >> system simple and that also makes it it easier to understand for users >> (but I might judge others by my own standards here?) For gcc this flag >> is -Wall, there isn't an extra binary either. > > There is still need for extra binary because some verification can be > slow sparse and hard to turn off without impact the sparse performance. > For example the ptr list ref count patch. It is execute at every ptrlist > bucket iteration. > > If there is no performance impact on when those verification > is turn off. Then yes, there is no need for a separate binary. > I haven't done concrete measurement of the slow down. > I just assume that there will be some. I would first implement doing everything in a single binary and only think about the complicated split in a "normal" and an "aggressive" sparse binary if the overhead is too high and people start wailing. (And even then I'd first check if using the equivalent of unlikely() in the kernel would help by assuming that passing --aggressive is "unlikely".) IMHO the cost of a complicated build system is to high to not first try the alternatives. Best regards Uwe
Attachment:
signature.asc
Description: OpenPGP digital signature
