[gem5-dev] Re: A few quick thoughts

[Gutierrez, Anthony via gem5-dev]

[AMD Public Use]

Hey, Jason perhaps you mentioned this somewhere but what is the reason for such 
a strong aversion to the template approach? It seems to solve the issue nicely 
with what seems to be a minor change in syntax. gem5 is C++, so we should allow 
users to write C++.

Tony

From: Jason Lowe-Power via gem5-dev 
Sent: Friday, September 18, 2020 8:05 AM
To: Gabe Black 
Cc: gem5 Developer List ; Jason Lowe-Power 

Subject: [gem5-dev] Re: A few quick thoughts

[CAUTION: External Email]
There is another option to keep the function-like syntax, but get the constexpr 
via templates: A preprocessor macro:

#define bits(val, first, last) bits(val)

The major downside is that we can't overload preprocessor macros. We'd have to 
have two name bits_const() and bits(), which I also don't like.

Personally, I strongly don't want to lose the function-like syntax for the bits 
function. I won't *block* the change, but I'll push back against the template 
syntax.

Cheers,
Jason

On Fri, Sep 18, 2020 at 5:02 AM Gabe Black 
mailto:gabebl...@google.com>> wrote:
I spent some more time digging into 2, and while I didn't find anything that 
directly stated that you aren't allowed to do that, without explicit support I 
think it flies in the face of how C++ templates, types, etc. work to the point 
where if you *did* find a way to do it, it would almost certainly be a bug or 
an oversight in the standard somewhere. So unless they do adopt one of those 
standards I saw proposed and we wait a good number of years for it to be 
implemented in all the compilers we support (one said it targeted C++23) I 
think templates, while slightly gross, are really the only way to make it work.

Gabe

On Thu, Sep 17, 2020 at 2:53 PM Jason Lowe-Power 
mailto:ja...@lowepower.com>> wrote:


On Thu, Sep 17, 2020 at 2:48 PM Gabe Black via gem5-dev 
mailto:gem5-dev@gem5.org>> 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 
mailto:gem5-dev@gem5.org>> 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: 

[gem5-dev] Lots of GPU changes will be pushed soon.

[Gutierrez, Anthony via gem5-dev]

[AMD Official Use Only - Internal Distribution Only]

Hi All,

Jason asked me to send a heads up since I plan to push a bunch of GPU changes, 
mostly the ones seen on the first page of the log for my staging branch: 
https://gem5.googlesource.com/amd/gem5/+log/refs/heads/agutierr/master-gcn3-staging,
 fairly quickly as we have a stretch goal to get much of the GPU code in for 
the gem5 20 release. The code I'll be pushing will not be touching files 
outside of gpu-compute or arch/gcn3, if it does I'll wait for proper review. 
For the GPU changes they have been thoroughly reviewed by experts within AMD 
and pass a large suite of GPU application tests, so I don't imagine reviews are 
necessary for anything other than style, which should also have been vetted in 
our internal review process.

That said, I'll leave the code up for a day or two so folks can go through it, 
but I'll likely be pushing it with/without reviews pretty rapidly.

Thanks,
Tony
___
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