original tree for folded expressions

original tree for folded expressions

[Joachim Wieland]

I'm working on a plugin to report dependencies of a .c file to its
headers, i.e. what information from the headers is referenced from the
.c file.

This works pretty well for most stuff, but I really have a hard time
for anything that gets folded to a constant. The AST does no longer
have the original types/functions/constants but transforms them to
const ints in an early stage already.

I am looking at the AST from a plugin and a tree walking function
called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I
could hook into? If not, would it be acceptable to add the original
tree to a folded tree for analyzing tools like mine? If so, any hint
about how this can be implemented? From looking at it, it seems that
everything (?) is passed through fold_convert_loc.


Thanks

Re: original tree for folded expressions

[Diego Novillo]

On 11-09-16 12:05 , Joachim Wieland wrote:

> I am looking at the AST from a plugin and a tree walking function
> called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I
> could hook into? If not, would it be acceptable to add the original
> tree to a folded tree for analyzing tools like mine?

Not really.  Memory consumption would go through the roof.

However, you could try an approach similar to what Le-Chun implemented 
for -Wself-assign (which only exists in the google/main branch for now). 
  See EXPR_FOLDED in 
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01898.html.


Diego.

Re: original tree for folded expressions

[Joachim Wieland]

On Fri, Sep 16, 2011 at 1:37 PM, Diego Novillo <dnovillo@google.com> wrote:
> However, you could try an approach similar to what Le-Chun implemented for
> -Wself-assign (which only exists in the google/main branch for now).  See
> EXPR_FOLDED in http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01898.html.

Hm, I don't see how exactly this would solve my problem... The issue I
am facing is that references to necessary header files are optimized
away. Just knowing that an expression has been folded doesn't help
me... :-(

What I had in mind was to only keep additional copies of the original
subtrees if the node has been replaced completely by folding. I don't
see why memory consumption would go through the roof that way, this
would mean that a very high percentage of the code can be folded and
shrinked significantly which shouldn't be true in the general case. Of
course I see that it can be difficult to implement this, it might
require changes to every folding function.

Is there any function that I could create a hook for which still sees
an unfolded expression?

Thanks,
Joachim

Re: original tree for folded expressions

[Diego Novillo]

On 11-09-16 16:25 , Joachim Wieland wrote:

> Hm, I don't see how exactly this would solve my problem... The issue I
> am facing is that references to necessary header files are optimized
> away. Just knowing that an expression has been folded doesn't help
> me... :-(

Sorry, I was too cryptic.  The setting of EXPR_FOLDED would be the 
places where you want to capture the unfolded trees.

> What I had in mind was to only keep additional copies of the original
> subtrees if the node has been replaced completely by folding. I don't
> see why memory consumption would go through the roof that way, this
> would mean that a very high percentage of the code can be folded and
> shrinked significantly which shouldn't be true in the general case. Of
> course I see that it can be difficult to implement this, it might
> require changes to every folding function.

IIUC, for every folded tree you want to keep the original form, right? 
That causes increased memory consumption.

> Is there any function that I could create a hook for which still sees
> an unfolded expression?

Not really.  At least, not using plugins.  You'll need to modify the 
compiler for that.

If you are doing analysis this close to the original source, however, 
you may want to consider clang.  GCC does not try to keep its ASTs close 
to the original source.


Diego.