This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSoC proposal: Provide optimizations feedback through post-compilation messages


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 compilers
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 risky
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 LOT 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 talk:
http://vimeo.com/36579366)

> Hello all,
> 
> My name is Thibault Raffaillac, CS degree student at Kungliga Tekniska Högskolan,
> Stockholm, Sweden (in double-degree partnership with Ecole Centrale Marseille,
> France).
> GCC currently provides no concise way to inform the user whether it applied an
> expected optimization (ie, it "understood" the code). As a result, some will do
> premature optimizations when they do not trust the compiler, and some others
> will create overly convoluted code with blind belief in the compiler. This 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 on some
> very standard optimizations across vendors, or for some specific yet nice
> features I would indicate their specificity to GCC/an architecture.
> 
> The feedback would be triggered when compilation is successful, and display 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 applied 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 reduction was applied to replace '* 8' by '<< 3'
> test.c:xx:x: info: Basic block vectorization was applied to pack the 3 independent additions into a single SIMD instruction
> test.c:xx:x: info: GCC implements unordered_map as open-addressed hash tables, with double hashing probing
> 
> 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 what
> triggered them, cite the optimization name, and describe the consequence.
> 
> 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.
> 
> My academic background includes compiler construction, C programming and Human-
> Computer Interactions. I am very much interested in the usability of compilers
> (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.
> 
> If this can be of interest, suggestions are welcome!
> 
> Best regards,
> Thibault (http://www.csc.kth.se/~traf/)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]