Identifying Compiler Options to Minimize Energy Consumption by Embedded Programs
Hi Everyone, Firstly, thanks for the great reception we got at the GCC Cauldron - it was nice meeting you. This is just a quick follow up email with regards to the presentation (available here http://jpallister.com/wiki/images/4/44/Gcc-cauldron-low-power-9-jul-12.pdf). A quick recap of what this project is about: We hope to identify what effect a broad range of compiler options has on the energy consumption of different embedded platforms. To do this we are finding a set of relevant benchmarks, compiling them with different options and measuring their energy consumption on these platforms. Questions we'd like to answer: - Which set of benchmarks are suitable for embedded applications and representative of possible applications? - What compiler options have the most effect on the power consumption of the device? - Does choice of compiler make any difference (LLVM or GCC)? - Does optimizing for speed give the same results as optimizing for energy usage? - Does choice of architecture make a difference? We are very interesting in getting opinions and for everyone to be able to see the progress of this project, so a wiki has been set up. You can access the wiki here: http://jpallister.com/wiki I give you occasional updates here as the work progresses. All contributions and feedback are very welcome. Thanks, James Pallister
Re: GCC Cauldron: Notes from the C++ ABI BOF
On Wed, Jul 11, 2012 at 02:47:37PM +0200, Michael Matz wrote:
> On Wed, 11 Jul 2012, Ian Lance Taylor wrote:
>
> > We will modify g++ to support a type attribute indicating the version of
> > the type, as a string. This type attribute will be inherited by any
> > other type that uses it, as a class/struct member or via inheritance.
> > Type attributes will be concatenated as needed. This type attribute
> > will then be used in the mangled name of any function that takes a
> > parameter of a type with an attribute or returns a type with an
> > attribute. The type attribute will also be used in the mangled name of
> > any global variable whose type has an attribute.
>
> There are some technical details that need to be decided: Should every
> type affected have a different tag, or just one common (e.g. all of c++11
> types that differ would get "_cxx11"? Then, should the set of these tags
Multiple types that are changed at the same time (and have the type added to
all of them concurrently) can and should use the same string.
Then there is no way to have new list and old pair together (if you use
unmodified libstdc++ headers at least), either during compilation both will
have "cxx11" string in the new type attribute, or none, so either you are
using a new std::list and std::pair, or the old one (well, std::pair is a
bad example probably, std::string and std::list is good, what other types we
are going to change?).
> if there are multiple be regarded as unordered set? This would allow
I'd just sort the collected strings. The other option is to remember in
some canonical way in what order the various strings have been seen for the
first time.
> The question boils down to what we want to add to the mangled name of a
> type looking like so (or an function taking the equivalent number of
> arguments):
>
> class X {
> std::list l1; // all new lists
> std::list l2;
> std::list l3;
> std::list l4;
> std::pair p1; // the old pair
> };
Can't happen, unless the libstdc++ headers would allow e.g. preprocessor
macros or compiler options to tweak the type attributes of std::list and
std::pair individually (but, if it allows that, then they must not use the
same string, if it doesn't allow that, then it can).
Jakub
Re: GCC Cauldron: Notes from the C++ ABI BOF
On 20 July 2012 12:43, Jakub Jelinek wrote: > using a new std::list and std::pair, or the old one (well, std::pair is a > bad example probably, std::string and std::list is good, what other types we > are going to change?). I need to add a new virtual function and rename an existing virtual function for a base class in . That's for C++11 types only, but doing the change will create an incompatibility with previous releases. (I don't know whether it's better to just make that change while we still call C++11 support experimental or to wait and use the new type attribute to make it a different type with the "_cxx11" tag.) I think there are some changes needed to the hierarchy of exception classes, to add std::system_error as a base class of std::ios_failure. I don't know if adding move semantics to iostream classes can be done without ABI changes (I haven't looked into it.)
gcc-4.6-20120720 is now available
Snapshot gcc-4.6-20120720 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120720/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch revision 189733 You'll find: gcc-4.6-20120720.tar.bz2 Complete GCC MD5=79a5e45515ee3a7cafd1278519206c29 SHA1=d30cbb8967df011d21f4577aa9cc2138d46b5657 Diffs from 4.6-20120713 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Ad-hoc notes from the "pending patches" BOF at the GNU tools cauldron.
On Wed, 11 Jul 2012 11:01:37 +0300 (EEST) Dimitrios Apostolou wrote: > Replying to myself, I was just informed (thanks hp!) that there is the > "URL" field in bugzilla, where the owner of the bug can add one relevant > URL. I tried it and it's very useful, it would be even better if I could > add more than one. You want "See Also" which lets you add multiple URLs. -- fonts, gcc-porting toolchain, wxwidgets @ gentoo.org signature.asc Description: PGP signature
