On Thu, 2015-09-17 at 13:14 -0600, Jeff Law wrote: > On 09/17/2015 10:49 AM, David Malcolm wrote: > > > FWIW, I have a (very messy) implementation of this working for the C > > frontend, which gives us source ranges on expressions without needing to > > add any new tree nodes, or add any fields to existing tree structs. > > > > The approach I'm using: > > > > * ranges are stored directly as fields within cpp_token and c_token > > (maybe we can ignore cp_token for now) > > > > * ranges are stashed in the C FE, both (a) within the "struct c_expr" > > and (b) within the location_t of each tree expression node as a new > > field in the adhoc map. > > > > Doing it twice may seem slightly redundant, but I think both are needed: > > (a) doing it within c_expr allows us to support ranges for constants > > and VAR_DECL etc during parsing, without needing any kind of new tree > > wrapper node > > (b) doing it in the ad-hoc map allows the ranges for expressions to > > survive the parse and be usable in diagnostics later. > > > > So this gives us (in the C FE): ranges for everything during parsing, > > and ranges for expressions afterwards, with no new tree nodes or new > > fields within tree nodes. > > > > I'm working on cleaning it up into a much more minimal set of patches > > that I hope are reviewable. > > > > Hopefully this sounds like a good approach > So is the assumption here that the location information is or is not > supposed to survive through the gimple optimizers?
To be honest I hadn't given much thought to that stage; my hope is that most of the diagnostics have been issued by the time we're optimizing. In the proposed implementation the range information is "baked in" to the location_t (via the ad-hoc lookaside), so it's carried along wherever the location_t goes, and ought to have the same chances of survival within the gimple optimizers as the existing location information does. > If I understand > what you're doing correctly, I think the location information gets > invalidated by const/copy propagations. > > Though perhaps that's not a major problem because we're typically > propagating an SSA_NAME, not a _DECL node. Hmm. Well, if the location_t is being invalidated by an optimization, we're already losing source *point* information: file/line/column. Given that, losing range information as well seems like no great loss. Or am I missing something? (I am attempting to preserve the source_range data when block ptrs are baked in to the ad-hoc locations, if that's what you're referring to) Dave
