walk_tree has missing expressions in COND_EXPR when using the CFG tree

RESOLVED INVALID

Status

Firefox Build System
Source Code Analysis
RESOLVED INVALID
10 years ago
2 months ago

People

(Reporter: Benjamin Smedberg, Assigned: dmandelin)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Created attachment 334711 [details] [diff] [review]
walk_tree conditional-eating testcase, rev.1 

In stack.js I'm using walk_tree to find all the statement lists in a tree. However, I discovered that it's missing large hunks of code (basically anything in a conditional statement). I traced this back to the following problem:

When walk_tree encounters a COND_EXPR, operands()[0] is correct, but operands()[1] and [2] are "undefined", so I can't walk into the "if" or "else" conditions, making them essentially invisible.

I further narrowed this down: it only happens when the following call is made:
require({ after_gcc_pass: 'cfg' }). Theory: does this have something to do with gimplification?

Of course, outparams makes this call so it is active for all of our treehydra analysis passes.

Possible solutions:
* figure out why COND_EXPR doesn't have the correct operands
* allow the stack.js pass to run before CFG and outparams to run after it... this seems related to "the multiplexer" that taras keeps talking about but which I don't really understand.
(Assignee)

Comment 1

10 years ago
(In reply to comment #0)
> I further narrowed this down: it only happens when the following call is made:
> require({ after_gcc_pass: 'cfg' }). Theory: does this have something to do with
> gimplification?

It appears that gimplification changes COND_EXPRs to use gotos. So if you run with the default pass position I think you will see either an empty statement list or one containing a goto in operands 1 and 2. At least that's what I got in my test.

CFG building creates edges according to the gotos and removes operands 1 and 2 entirely.

> * allow the stack.js pass to run before CFG and outparams to run after it...

One option may be to run your analysis in the "AST" hook, which I believe is new to Treehydra and is separate from and before the plugin pass hook. I don't know if the AST is the data you want, though. But if you don't like those gotos introduced by gimplification, maybe this is just the thing you need.

> this seems related to "the multiplexer" that taras keeps talking about but
> which I don't really understand.

I think the multiplexer is supposed to be a plugin than loads and runs multiple C plugins, so I don't think it applies here (unless it's smart enough to "load" and run the same plugin twice with different arguments). 

The first solution that comes to mind is to let Treehydra manage two passes, which can be positioned independently. This mechanism would suffice, but the policy aspect of managing which passes are active across multiple independently deployable plugins sounds a bit scary.
(Reporter)

Comment 2

10 years ago
Resolving this INVALID: I switch the stack checker to use process_cp_pre_genericize
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID

Updated

2 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.