1133255 - Ion: Assertion failure: !iter->hasLiveDefUses()

Status: RESOLVED FIXED

(Core :: JavaScript Engine: JIT, defect)

Description

[Douglas Crosher [:dougc]]

While experimenting with moving GVN after range analysis, the following failure was noted. This also depended on some array access optimizations, but GVN already runs before and after range analysis, and perhaps the patterns being explored tickled an existing issue.

The failing def is in Block 2, Add1036, and the following might be relevant:

[GVN]       Recording Add1036
[GVN]       Replacing Add332 with Add1036
[GVN]       Discarding dead Add332

After GVN there is an assertion failure:
Assertion failure: !iter->hasLiveDefUses(), at src/jit/IonAnalysis.cpp:1928

This assertion is only checked when iter->isRecoveredOnBailout().

Could this be an existing issue, or is it more likely that local changes have broken invariants?

Are the Ion Logs still supported? I see the 'logs' option in IONFLAGS help, and have off thread compilation disabled. Has the code been removed? Is there another option for examining the MIR?

Comment 1

[Nicolas B. Pierron [:nbp]]

GVN and LICM are not aware of recover instructions, the only instruction which are recovered on bailout at the time of GVN and LICM, are the MObjectState / MArrayState instructions, which have no way to be handled by GVN / LICM.

Range Analysis can insert a few of these instructions when truncating.  These instructions are clones of the original, which are needed for recovering the non-truncated result, in case the result is captured by a resume point, and if the instruction had removed uses.

This can be fixed by either telling GVN to skip optimizations on recovered instruction, or to make sure that the recover on bailout flag is used as part of the hash computation used by GVN.

(In reply to Douglas Crosher [:dougc] from comment #0)
> Are the Ion Logs still supported?

Only on debug build.

Comment 2

[Hannes Verschore [:h4writer]]

(In reply to Douglas Crosher [:dougc] from comment #0)
> Could this be an existing issue, or is it more likely that local changes
> have broken invariants?

That is very likely. If you have more context I can take a look? Eagerly closing this bug. Don't hesitate to open a new bug or or reopen this.