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

Reply via email to