Re: [gimplefe] [gsoc16] Gimple Front End Project
On Mon, Mar 14, 2016 at 7:27 PM, Michael Matz wrote: > Hi, > > On Thu, 10 Mar 2016, Richard Biener wrote: > >> Then I'd like to be able to re-construct SSA without jumping through >> hoops (usually you can get close but if you require copies propagated in >> a special way you are basically lost for example). >> >> Thus my proposal to make the GSoC student attack the unit-testing >> problem by doing modifications to the pass manager and "extending" an >> existing frontend (C for simplicity). > > I think it's wrong to try to shoehorn the gimple FE into the C FE. C is > fundamentally different from gimple and you'd have to sprinkle > gimple_dialect_p() all over the place, and maintaining that while > developing future C improvements will turn out to be much work. Some > differences of C and gimple: > > * C has recursive expressions, gimple is n-op stmts, no expressions at all > * C has type promotions, gimple is explicit > * C has all other kinds of automatic conversion (e.g. pointer decay) > * C has scopes, gimple doesn't (well, global and local only), i.e. symbol > lookup is much more complicated > * C doesn't have exceptions > * C doesn't have class types, gimple has > * C doesn't have SSA (yes, I'm aware of your suggestions for that) > * C doesn't have self-referential types > * C FE generates GENERIC, not GIMPLE (so you'd need to go through the > gimplifier and again would feed gimple directly into the passes) > > I really don't think changing the C FE to accept gimple is a useful way > forward. So I am most worried about replicating all the complexity of types and decl parsing for the presumably nice and small function body parser. In private discussion we somewhat agreed (Micha - correct me ;)) that iff the GIMPLE FE would replace the C FE function body parsing completely (re-using name lookup infrastructure of course) and iff the GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE and a GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body) then "re-using" the C FE would be a way to greatly speed up success. The other half of the project would then be to change the pass manager to do something sensible with the produced GIMPLE as well as making our dumps parseable by the GIMPLE FE. Richard.
Re: Compiler support for erasure of sensitive data
On Wed, Mar 9, 2016 at 2:09 PM, Segher Boessenkool wrote: > [ Please don't top-post. ] > > On Wed, Mar 09, 2016 at 11:23:22AM -0300, Andres Tiraboschi wrote: >> We are developing this feature for x86_64 >> I want to see which registers are being used by the current function >> for returning a value or as arguments. >> I traverse the rtl looking for clobbered registers, but I don't know >> how to find which registers are arguments from the current function >> and which are used for storing the return value. How do you suggest to >> do this? > > You can probably do something with diddle_return_value. > > > Segher Hi, we attached a patch in: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69976 Please take a look!
Re: [gimplefe] [gsoc16] Gimple Front End Project
Hi, On Tue, 15 Mar 2016, Richard Biener wrote: > So I am most worried about replicating all the complexity of types and > decl parsing for the presumably nice and small function body parser. > > In private discussion we somewhat agreed (Micha - correct me ;)) that > iff the GIMPLE FE would replace the C FE function body parsing > completely (re-using name lookup infrastructure of course) and iff the > GIMPLE FE would emit GIMPLE directly (just NULL DECL_SAVED_TREE and a > GIMPLE seq in DECL_STRUCT_FUNCTION->gimple_body) then "re-using" the C > FE would be a way to greatly speed up success. Yeah, that's a fair characterization of our discussion. What I'm most worried about with mixing C and gimple parsing are several things: * silently accepting C-like code that actually isn't supposed to be gimple, i.e. I fear we muddle the water by attaching something to an existing large blob without a very clear separation * uglifying the C parser so much that the changes become unacceptable * Parsing gimple, but going though GENERIC; I want to directly create GIMPLE Separating the type/decl parsing and function body parsing would help with all three things, and will give you a working type parser without actually copying code around, so that's a plus. (Of course, putting it into an existing front-end might also be less fun than writing one from scratch, but that's not my main point :) ). > The other half of the project would then be to change the pass manager > to do something sensible with the produced GIMPLE as well as making our > dumps parseable by the GIMPLE FE. Definitely the dumping part needs to be developed somewhat in lock-step with the parser; the pass manager infrastructure should be started somewhat halfway into the project, yes. Ciao, Michael.
gcc-5-20160315 is now available
Snapshot gcc-5-20160315 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160315/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 234238 You'll find: gcc-5-20160315.tar.bz2 Complete GCC MD5=decca4495aef232cdefd67e6c872e4d5 SHA1=dc17f4ba2ab939ca81257b2ea3a54a78cfc24691 Diffs from 5-20160308 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.
