From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24214 invoked by alias); 2 Apr 2012 19:57:40 -0000 Received: (qmail 24201 invoked by uid 22791); 2 Apr 2012 19:57:38 -0000 X-SWARE-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,BAYES_20,RCVD_IN_HOSTKARMA_NO,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-2.sys.kth.se (HELO smtp-2.sys.kth.se) (130.237.32.160) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Apr 2012 19:57:25 +0000 Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 87E3C14F111 for ; Mon, 2 Apr 2012 21:57:23 +0200 (CEST) Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id YNKEiVAKo22N for ; Mon, 2 Apr 2012 21:57:22 +0200 (CEST) Received: from EXHUB1.ug.kth.se (exhub1.ug.kth.se [130.237.32.134]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 6AF8A14F135 for ; Mon, 2 Apr 2012 21:57:22 +0200 (CEST) Received: from EXDB1.ug.kth.se ([169.254.1.209]) by EXHUB1.ug.kth.se ([130.237.32.134]) with mapi id 14.01.0339.001; Mon, 2 Apr 2012 21:57:21 +0200 From: Thibault Raffaillac To: "gcc@gcc.gnu.org" Subject: Re: GSoC proposal: Provide optimizations feedback through post-compilation messages Date: Mon, 02 Apr 2012 19:57:00 -0000 Message-ID: <47466B24D5352C4AA77737202B165839227F58F6@EXDB1.ug.kth.se> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00035.txt.bz2 Bump! Let me renew my interest in contributing through GSoC with post-compilation feedback (This was not an early april joke). Do you think it could lead to = an acceptable GSoC proposal? (mentor interested?) @Tomasz: On the interaction side I totally agree that communication between compiler= and programmer is scarce (and there is room for improvement). Focusing too soon= on the editor would overlook the vast users needs though, as: _ some users do not use an IDE (and will kindly refuse); _ some users do not need more communication, as they already know what GCC = can and cannot do; _ some users do not want more communication, as they have other business to focus on; I think the editor being split from the compiler is good thing. There still exist tools to expose static analysis data from the compiler (and choose the editor to visualize it with), but fundamentally they are assisting him/her rather than helping him/her improve. Instead of gathering loads of data on = the optimizations/analysis performed, and filtering it for visualization by the user, we could relate the optimization technique used so that the user truly knows what GCC is capable of (instead of guessing by observation). My proposal is thus not to be confused with a static analysis visualization: the programmer learns what techniques are implemented in GCC (or in compile= rs in general), how to write code that is more easily compiled, and can further browse the Internet for detailed theory on the techniques involved. The point on the possible-optimizations-which-could-be-enabled-if-specific- -constraint-is-lifted is particularly interesting, but is also extremely ri= sky if the compiler makes a stupid remark on a constraint which can "obviously" (for the programmer) not be lifted. If ever, I would introduce it with a LO= T of care. Thibault ps: As for an editor with real-time feedback on static analysis and more, I= am 100% with you :) (and there are some promising prototypes, like in this tal= k: http://vimeo.com/36579366) > Hello all, >=20 > My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska H= =F6gskolan, > Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marse= ille, > France). > GCC currently provides no concise way to inform the user whether it appli= ed an > expected optimization (ie, it "understood" the code). As a result, some w= ill do > premature optimizations when they do not trust the compiler, and some oth= ers > will create overly convoluted code with blind belief in the compiler. Thi= s is > especially relevant for users non-initiated to the internals of GCC. > The project I would like to propose is a feedback for the optimizations > performed by GCC. To avoid binding users to the compiler, I would focus o= n some > very standard optimizations across vendors, or for some specific yet nice > features I would indicate their specificity to GCC/an architecture. >=20 > The feedback would be triggered when compilation is successful, and displ= ay a > couple of different messages each time it is run: > gcc --feedback test.c > test.c:xx:x: info: All operands being constant, constant folding was appl= ied to assign '2560' to 'a' > test.c:xx:x: info: GCC could not fold constants here because... > test.c:xx:x: info: As integers are stored in binary format, strength redu= ction was applied to replace '* 8' by '<< 3' > test.c:xx:x: info: Basic block vectorization was applied to pack the 3 in= dependent additions into a single SIMD instruction > test.c:xx:x: info: GCC implements unordered_map as open-addressed hash ta= bles, with double hashing probing >=20 > As a difference with the internal verbose messages, here they would form = a set, > and the system would remember those already displayed and decrease their > frequency of occurence between compilations. All messages would explain w= hat > triggered them, cite the optimization name, and describe the consequence. >=20 > As for the work plan, it would consist in: > _ Enumerating all possible messages in the messages set. > _ Implementing a function receiving feedback from each optimization unit = and > choosing whether to display it: info_printf(enum INFO_INDEX, const char= *, ...); > _ Write a formatting guide for adding messages in the set. >=20 > My academic background includes compiler construction, C programming and = Human- > Computer Interactions. I am very much interested in the usability of comp= ilers > (on which I am currently carrying my degree thesis - > http://www.csc.kth.se/~traf/traf-sketch.pdf) and thus would be glad to > contribute to GCC. >=20 > If this can be of interest, suggestions are welcome! >=20 > Best regards, > Thibault (http://www.csc.kth.se/~traf/)