Investigate generalizing Float32 analysis to FilterTypeSet and other noop

NEW
Unassigned

Status

()

Core
JavaScript Engine: JIT
P5
normal
3 years ago
2 years ago

People

(Reporter: bbouvier, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Ideally, MFilterTypeSet should behave as a no-op during the float32 analysis, that is, propagating the producer flag from its input and the consumer flag from its uses. However, bug 1207449 showed that this is problematic because of phis that form a cycle, in which at least one phi has a MFilterTypeSet as an input.

While the band-aid patch in bug 1207449 prevents this kind of issue, it's overly conservative and a more generic approach could be taken. In the Float32 analysis, instead of propagating the can{Produce,Consume}Float32 flags only for MPhis, we could do the same work for MFilterTypeSet. Maybe even for other MIR nodes that should behave as noop, though I am unsure there are any at the moment. Opening this bug to investigate whether it's worth it.

Updated

2 years ago
Blocks: 1307062
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.