Hi, On Wed, 13 Nov 2013, Andrew MacLeod wrote:
> There needs to be a place which has gimple componentry that is not > related to or require a statement. gimple.h is becoming the home for > just 0gimple statements. There are 3 (for the moment) major classes of > things that are in statements and are also used by other parts of the > compiler .. Types, Decls, and Expressions. Actually I wouldn't say gimple statements contain expressions. They refer to objects (and unfortunately also sometimes to types directly, namely in the call stmt and in the exception statements, though the latter don't exist anymore after lowering). It's those objects which have types. Currently those objects are trees and hence can be more complex than just singletons (which are the decls, constants and ssa names), that is most of the SINGLE_RHS objects. If you want to get rid of trees you somehow need to represent those objects in a different way, but they still aren't expressions in the common meaning. E.g. there won't ever be something like a gimple arithmetic addition expression (or I hope there never will be). It's always a gimple statement that assigns the addition result somewhere. Even the non-singleton objects don't exist in isolation, they're always part of some action (i.e. statement) to operate on those objects. That's why I think talking about a gimple expression as if they were somehow some stand-alone concept is fairly confusing, and introducing it now as if it would somewhen exist would lead to going down some inferior design paths. > Its true that gimple-tree would in fact be a more appropriate name at > the moment, but these gimple-* files are the core ones I'll be changing > first, so the tree part would no longer be meaningful. the 'expr' part > is suppose to represent the abstract purpose... The stuff required to > represent an expression in gimple IL. And yes, that is currently a tree > :-) Put another way: what do you envision that gimple expressions would be. For example what would you propose we could do with them? Ciao, Michael.
