On 7/19/18, Jeff Law <l...@redhat.com> wrote: > On 07/10/2018 05:09 AM, colinb2 . wrote:
> Improvements to compile time behavior are always worth considering. The points you make below about wide_int might address this, albeit in a somewhat different way from the way I am proposing. > So a key issue with GCC is that for nontrivial code to be included in > GCC, the code's author must assign their copyright ownership to the FSF. That's OK for choose_multiplier_v2 which is what I'm suggesting as a replacement for choose_multiplier. >> The idea is using "wide int" seems slow compared to "unsigned HOST_WIDE_INT", >> so it makes sense to avoid using "wide int" as much as possible. > Sure, but the use of wide_int types has certain advantages and if > possible we'd like that class to be just as efficient as a HOST_WIDE_INT > for common operations on 32 and 64 bit types. That makes sense, and *if* you can do it has some advantages over what I was proposing. Reviewing my code I realised that I needed to split off two special cases (i) d=1 and (ii) PRECISION<lgup. I've put an updated version of choose_multiplier_v2 here: https://github.com/colinb2r/expmed2 > In fact, for 32 and 64 bit types, wide_int is supposed to generate the > same code as HOST_WIDE_INT. At least that was the state in 2013 when > wide_int was introduced. So it may be worth spending some time figuring > out why changing the types changes the performance. I was assuming that it was something intrinsic to the way wide_int had to be implemented that made it substantially slower than fixed width like HOST_WIDE_INT, and I was also assuming that earlier versions of choose_multiplier which didn't use wide_int, but used an equivalent extended precision would have a similar lack of speed? I did look at earlier versions of choose_multiplier, and I have a vague recollection that one of the earlier implementations basically used HOST_WIDE_INT throughout, using auxiliary variables to indicate that mlow and mhigh need an extra bit. Looked at like that it becomes sort of obvious why an extended precision integer is likely to be slower than a fixed width HOST_WIDE_INT: if nothing else, there is more "housekeeping" involved? > If you're going to argue to use HOST_WIDE_INT, then you'll have to think > about how you're going to support 128bit or wider target data types > which is the whole point behind the introduction of wide_int. > > Anyway, I think these higher level questions/concerns need to be > addressed before we can reasonably discuss replacing wide_int with > HOST_WIDE_INT. In principle I agree with both these paragraphs. But that said the current choose_multiplier happily (?) switches between using wide_int and HOST_WIDE_INT, and at its end the multiplier is of type unsigned HOST_WIDE_INT, so if we're focussing on choose_multiplier (rather than the broader issue of making wide_int faster in general) I don't think these valid points actually apply to choose_multiplier? If what you were saying was strictly true for choose_multiplier, then it could use wide_int throughout, only switching to HOST_WIDE_INT at the end? But that's not how it's written. > WRT algorithmic changes. ISTM it would be best to address those > separately from the wide_int vs HOST_WIDE_INT discussion. An > algorithmic change should have the same impact regardless of whether > we're using wide_int or HOST_WIDE_INT. Yes. Or to be precise, wide_int ought to be able to replace HOST_WIDE_INT, but the reverse might not be true? Taking choose_multiplier as an example, we must be rather more careful going from wide_int to HOST_WIDE_INT than going from HOST_WIDE_INT to wide_int? > Rather than attaching new implementations, the generally preferred > packaging is diffs against the trunk. That makes sense. Unfortunately I don't feel I have the competence to do that, but that's a bridge that can if necessary be crossed in an appropriate way when the time comes? > Jeff Thanks for your pertinent comments. I must confess I had rather assumed that after over a week without any "bites" that my post wasn't going to attract any comments, so finding your response just now was a welcome surprise.
