Closed Bug 975076 Opened 7 years ago Closed 6 years ago

--disable-unified-compilation does not disable unified compilation of binding code

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bwc, Unassigned)

Details

When using --disable-unified-compilation, the binding code still seems to be compiled in a unified fashion (eg; UnifiedBindings10.cpp). This means that modification to a binding invalidates a lot of object code, and adding/removing a binding can invalidate even more (since that causes stuff to move around). This is not such a big deal on a normal build, but it really trashes incremental ASan builds.
I'm hacking on this a little bit, but finding places where non-unified compilation can't work. AttrBinding.cpp, for example, relies on some earlier binding picking up includes for it.
Note the unification of sources for bindings predate unified compilation and is not working exactly the same way.
(In reply to Byron Campen [:bwc] from comment #1)
> I'm hacking on this a little bit, but finding places where non-unified
> compilation can't work. AttrBinding.cpp, for example, relies on some earlier
> binding picking up includes for it.

If this happens, it is a bug.  Please file in Core/DOM with STR.
(In reply to Byron Campen [:bwc] from comment #0)
> When using --disable-unified-compilation, the binding code still seems to be
> compiled in a unified fashion (eg; UnifiedBindings10.cpp). This means that
> modification to a binding invalidates a lot of object code, and
> adding/removing a binding can invalidate even more (since that causes stuff
> to move around). This is not such a big deal on a normal build, but it
> really trashes incremental ASan builds.

Why is it a bigger deal for ASan builds than for normal builds?
Flags: needinfo?(docfaraday)
(In reply to Nathan Froyd (:froydnj) from comment #4)
> (In reply to Byron Campen [:bwc] from comment #0)
> > When using --disable-unified-compilation, the binding code still seems to be
> > compiled in a unified fashion (eg; UnifiedBindings10.cpp). This means that
> > modification to a binding invalidates a lot of object code, and
> > adding/removing a binding can invalidate even more (since that causes stuff
> > to move around). This is not such a big deal on a normal build, but it
> > really trashes incremental ASan builds.
> 
> Why is it a bigger deal for ASan builds than for normal builds?

Because compiling is much more expensive on asan; for non-asan, the time saved by unifying outweighs the extra compilation you need to do when one binding changes (a change to one binding forces recompilation of 16 bindings), because that extra compilation work is not incredibly expensive. For asan, the compilation penalty is more than an order of magnitude worse (adding or removing a binding, with no other change, can easily cause an incremental asan build to take more than an hour on good hardware).
Flags: needinfo?(docfaraday)
(In reply to Mike Hommey [:glandium] from comment #2)
> Note the unification of sources for bindings predate unified compilation and
> is not working exactly the same way.

Yeah, I saw. I'm wondering if it might be useful to teach the unification code to base the filenames on the input filename in the degenerate case where the number of files per unified file is 1 (eg; UnifiedAttrBinding.cpp contains just the include for AttrBinding.cpp, plus the error-checking boilerplate). This would solve the problem I'm facing with relatively little code, plus would allow me to still catch errors that the boilerplate code checks for.
We're removing support for non-unified builds in bug 1121000.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.