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 -- 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 < gem5-dev@gem5.org> wrote: > Hey Gabe, > > On Thu, Sep 17, 2020 at 4:46 AM Gabe Black via gem5-dev <gem5-dev@gem5.org> > 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 -- gem5-dev@gem5.org >> To unsubscribe send an email to gem5-dev-le...@gem5.org >> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s > > _______________________________________________ > gem5-dev mailing list -- gem5-dev@gem5.org > To unsubscribe send an email to gem5-dev-le...@gem5.org > %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
_______________________________________________ gem5-dev mailing list -- gem5-dev@gem5.org To unsubscribe send an email to gem5-dev-le...@gem5.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
