On Tue, Sep 6, 2016 at 8:14 AM, Nathan Sidwell <nat...@acm.org> wrote: > On 09/06/16 06:57, David Edelsohn wrote: > >> What about Jakub's comment in the PR? >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378#c6 > > > This needs addressing. Can you clarify PPC behaviour, because I may have > misunderstood: > > 1) PPC currently has 64 bit counters -- but cannot support 64bit atomic ops > in 32 bit mode. > > 2) PPC currently has 32 bit counters anyway.
The rs6000 port ABIs implement 64 bit "long long" type. The current code uses LONG_LONG_TYPE_SIZE for the counters. I assume that most ports don't support native 64 bit atomic operations in 32 bit ABI -- PowerPC does not. The previous code allowed gcov type to be overridden, but I don't think that it was 32 bit on most targets. > > I had interpreted the comment to be implying #2, but now I'm not so sure. > >> The proposed patch seems wrong or at least incomplete. The recent >> change is imposing a 64 bit DImode counter when producing 32 bit code. >> PowerPC does support 64 bit atomic operations in 32 bit mode. > > > I'm presuming you've missed a 'NOT' in that sentence. Yes, I omitted a "NOT". PowerPC64 has 64 bit atomics, but PowerPC32 subset only provides 32 bit atomics in the ISA. If the counters always should be 64 bit, then a poor-man's 64 bit atomic operation proposed by Jakub seems like a better solution. Thanks, David > >> Was there a design decision that profile counters always should be 64 >> bits? Either 32 bit targets won't support multi-threaded profiling or >> 32 bit targets can overflow the counter sooner. > > > >> Which is worse? >> Which is more likely? > > > My initial thought is that it is probably awkward to support 2 different > sized counter types in the 'same' config. I.e. 64-bit single-threaded > counters and 32-bit threaded counters. > > nathan
