On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev <[email protected]> wrote:
> 1. Sounds good, I'll hopefully have some time to put together a CL in no > too long (weekend?). > > 2. I 5ries to figure out a way to do it without the template that wasn't > really gross a somewhat fragile and wasn't able to, but that would > definitely be preferable. I'll keep thinking about it, but the internet > didn't seem to have any ideas either. Unfortunately using constexpr won't > work like that Jason, although I wish it did and found a couple unadopted > (as far as I know) standards proposals to that effect. > Yeah, that's what I found, too :). > > 3. Sounds good. Likely this weekend? > > Gabe > > On Thu, Sep 17, 2020, 1:15 PM Bobby Bruce via gem5-dev <[email protected]> > wrote: > >> 1) Seems fine to me. >> >> 2) I remember looking into this and I agree with Jason, it involves >> template magic which I'm not a huge fan of. I feel like in order to add >> these compile time asserts we'd be sacrificing some >> readability/ease-of-usability of bitfields.hh. This may just be a "me >> thing", but something about templates confuse me whenever I need to deal >> with them. >> >> 3) In truth, our minimum supported Clang version is 3.9 in practise (We >> even state on our website's building documentation that we support Clang >> 3.9 to 9: http://www.gem5.org/documentation/general_docs/building). I >> didn't realize we still have "3.1" hardcoded in the SConscript and would be >> happy for this to be bumped up to 3.9. Our compiler tests do not test with >> versions of clang before 3.9, so, at present, we aren't doing much to help >> those using versions older than 3.9. I'd love to bump up to c++14 also. >> While I'm sure there are plenty of good reasons, I personally would like to >> use C++14's deprecation attribute for if/when we start deprecating gem5 C++ >> APIs: https://en.cppreference.com/w/cpp/language/attributes/deprecated >> > We already do use the deprecated attribute (see https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#55 ). We should be able to get rid of this: https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#93 And maybe this: https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/src/base/compiler.hh#69 > >> -- >> Dr. Bobby R. Bruce >> Room 2235, >> Kemper Hall, UC Davis >> Davis, >> CA, 95616 >> >> web: https://www.bobbybruce.net >> >> >> On Thu, Sep 17, 2020 at 8:25 AM Jason Lowe-Power via gem5-dev < >> [email protected]> wrote: >> >>> Hey Gabe, >>> >>> On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev < >>> [email protected]> wrote: >>> >>>> 1. Use __builtin_expect() for panic, fatal, etc. Preexisting library >>>> functions like assert probably already have this, but our versions don't >>>> and have similar behavior patterns. This should improve performance. >>>> >>> >>> Seems like a good idea. It shouldn't hurt anything. >>> >>> >>>> >>>> 2. Create template versions of the bits, etc functions in bitfields.hh >>>> which use static_assert to verify that the bounds are in the right order. >>>> Unless the bounds change at runtime (probably very uncommon in practice) >>>> >>> >>> I like the idea of static asserts, but don't like the change in the >>> syntax away from a simple function call. >>> >>> Would it be possible to instead use a constexpr function parameter? >>> >>> What we would really like is >>> >>> template <class T> >>> inline >>> T >>> bits(T val, *constexpr *int first, *constexpr *int last) >>> { >>> int nbits = first - last + 1; >>> *static*_assert((first - last) >= 0); >>> return (val >> last) & mask(nbits); >>> } >>> >>> However, after spending 15-30 minutes researching it doesn't seem like >>> this is easy to do today. Gabe... you seem to know much more template >>> magic. Maybe there's a way? >>> >>> >>>> bits(foo, 2, 1) => bits<2, 1>(foo) >>>> >>>> Then we get the free compile time checking of bounds most of the time >>>> without big overhead otherwise. Something like this: >>>> >>>> template <int first, int last, typename T> >>>> constexpr T >>>> bits(T val) >>>> { >>>> static_assert(first > last); >>>> return bits(val, first, last); >>>> } >>>> >>>> 3. Our new min gcc is version 5 which supports c++14. Our min clang is >>>> 3.1 which does not, but 3.4 does. Do we want to bump the min clang version >>>> up and move from C++11 to C++14? C++17 has more compelling features, but >>>> C++14 fixed some annoyances, at least according to wikipedia: >>>> >>>> https://en.wikipedia.org/wiki/C%2B%2B14 >>>> >>> >>> Yeah, I don't see any reason not to bump our minimum clang version. If >>> we do go up to c++14, we can simplify compiler.hh significantly. >>> >>> Thanks for starting this conversation! >>> >>> Cheers, >>> Jason >>> >>> >>>> >>>> >>>> Gabe >>>> _______________________________________________ >>>> gem5-dev mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >>> >>> _______________________________________________ >>> gem5-dev mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s >> >> _______________________________________________ >> gem5-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- [email protected] To unsubscribe send an email to [email protected] %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
