on 2021/8/12 下午11:51, Segher Boessenkool wrote: > On Thu, Aug 12, 2021 at 10:10:10AM +0800, Kewen.Lin wrote: >>> + enum rs6000_builtins vname = RS6000_BUILTIN_COUNT; >>> >>> Using this as a flag value looks unnecessary. Is this just being done to >>> silence a warning? >> >> Good question! I didn't notice there is a warning or not, just get used to >> initializing variable >> with one suitable value if possible. If you don't mind, may I still keep >> it? Since if some >> future codes use vname in a path where it's not assigned, one explicitly >> wrong enum (bif) seems >> better than a random one. Or will this mentioned possibility definitely >> never happen since the >> current uninitialized variables detection and warning scheme is robust and >> should not worry about >> that completely? > > It is a bad idea to initialise things unnecessary: it hinders many > optimisations, but much more importantly, it silences warnings without > fixing the problem. >
OK, I've made it uninitialized in v2. :-) I believe the context here is simple and the uninit-ed var detector can easily catch and warn the bad thing in future. Sorry for chasing dead ends, I don't follow how it can hinder optimizations here, IIUC it would be optimized as a dead store here? As to the warning, although there is no warning, I'd expect it causes ICE since the init-ed bif name isn't reasonable for generation. Wouldn't it be better than warning? Sometimes we don't have a proper value for initialization, I agree it should be better to just leave it be, but IMHO it isn't the case here. :) BR, Kewen >>> + if (vname != RS6000_BUILTIN_COUNT >>> >>> Check is not necessary, as you will have returned by now in that case. >> >> Thanks for catching, I put break for "default" initially, didn't noticed the >> following condition >> need an adjustment after updating it to early return. Will fix it. > > Thanks :-) > > > Segher >
