on 2021/9/21 下午8:03, Segher Boessenkool wrote: > Hi! > > On Tue, Sep 21, 2021 at 01:47:19PM +0800, Kewen.Lin wrote: >> on 2021/9/18 上午6:26, Segher Boessenkool wrote: >>>> + if (data->nloads > (unsigned int) rs6000_density_load_num_threshold >>>> + && load_pct > (unsigned int) rs6000_density_load_pct_threshold) >>> >>> Those variables are unsigned int already. Don't cast please. >> >> Unfortunately this is required by bootstrapping. The UInteger for the >> param definition is really confusing, in the underlying implementation >> it's still "signed". If you grep "(unsigned) param", you can see a few >> examples. I guess the "UInteger" is mainly for the param value range >> checking. > > Huh, I see. Is that a bug? It certainly is surprising! Please open a > PR if you think it could/should be improved, put me on Cc:? >
I guessed it's not a bug, "UInteger" is more for the opt/param value range checking, but could be improved. PR102440 filed as you suggested. :) >>>> +-param=rs6000-density-pct-threshold= >>>> +Target Undocumented Joined UInteger Var(rs6000_density_pct_threshold) >>>> Init(85) IntegerRange(0, 99) Param >>> >>> So make this and all other percentages (0, 100) please. >> >> I thought 99 is enough for the RHS in ">". just realized it's more clear >> with 100. Will fix! > > 99 will work fine, but it's not the best choice for the user, who will > expect that a percentage can be anything from 0% to 100%. > >>>> +When costing for loop vectorization, we probably need to penalize the >>>> loop body cost if the existing cost model may not adequately reflect >>>> delays from unavailable vector resources. We collect the cost for >>>> vectorized statements and non-vectorized statements separately, check the >>>> proportion of vec_cost to total cost of vec_cost and non vec_cost, and >>>> penalize only if the proportion exceeds the threshold specified by this >>>> parameter. The default value is 85. >>> >>> It would be good if we can use line breaks in the source code for things >>> like this, but I don't think we can. This message is mainly used for >>> "--help=param", and it is good there to have as short messages as you >>> can. But given the nature of params you need quite a few words often, >>> and you do not want to say so little that things are no clear, either. >>> >>> So, dunno :-) >> >> I did some testings, the line breaks writing can still survive in the >> "--help=param" show, the lines are concatenated with " ". Although >> there seems no this kind of writing practices, I am guessing you want >> me to do line breaks for their descriptions? If so, I will make them >> short as the above "Target Undocumented..." line. Or do you want it >> to align source code ColumnLimit 80 (for these cases, it would look >> shorter)? > > It would help if was more readable in the surce code, one line of close > to 500 columns is not very manageable :-) > > But the thing that matters is what it will look like in the --help= > output (and/or the manual). > OK, I've used ColumnLimit 80 for that. The outputs in --help= before/after the line breaks look the same (smoother than what I can expect). :) Committed in r12-3767, thanks! BR, Kewen
