641798 - verify PGO in build logs

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[[e-mail] (:bhearsum)]

Bug 641325 describes a situation where we stopped PGO optimization all of JS, and didn't catch it. The logs show clearly that it's not being optimized, but we weren't looking for it:
mozjs.pgd(0) : warning C4961: No profile data was merged into 'mozjs.pgd', profile-guided optimizations disabled

We should verify these, probably in Buildbot's createSummary(). One idea for doing so:
- Define a list of DLLs that we expect to be PGO optimized
- Subclass Compile
- Override createSummary, search for a line like the above for every DLL that needs optimization
- If any of them aren't found, turn orange, add a new log, and put something in it that the Tinderbox Summary functions will pick up.

One tricky part of this is that we can only do this check as part of Win32 opt builds, we'll have to find a way to turn it off for other types.

Comment 1

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

We can teach the build system to treat the "PGO disabled" warning as an error that stops compilation, which I think is much cleaner than this.

Comment 2

[[e-mail] (:bhearsum)]

In that case, off to Core: Build Config!

Comment 3

[Mike Hommey [:glandium]]

On the other hand, there are plenty of files that don't have profile information because the code is not covered by profiling...

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

There's plugin-container.exe and browsercomps.dll, which are arguably bugs, and then a bunch of test code that we can ignore the warnings on.

We have to be a little clever about it, certainly.

Comment 5

[Mike Hommey [:glandium]]

(In reply to comment #4)
> There's plugin-container.exe and browsercomps.dll, which are arguably bugs, and
> then a bunch of test code that we can ignore the warnings on.

... and a lot of code from libjpeg, xpcom, zlib, uconv, etc., etc., and even from js/src.

Comment 6

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

which ends up in libxul and is PGOd ...

Comment 7

[Mike Hommey [:glandium]]

(In reply to comment #6)
> which ends up in libxul and is PGOd ...

Except you get the PGO disabled warning way before linking, with gcc. I know the bug has been reported for windows PGO, but since we're going to enable PGO on Linux soonish, this would be nice to have there too.

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Ah ... that explains why we're talking past each other ;-)

Comment 9

[s793016]

Sorry, my English is very very poor.

I found something maybe useful.

1.
"*.pgd(0) : warning C4961: No profile data was merged into '*.pgd', profile-guided optimizations disabled"

comm-release/config/rules.mk
======
@@ -937,11 +937,11 @@
 ifneq (,$(SHARED_LIBRARY)$(PROGRAM))
 export::
 ifdef PROGRAM
	$(PYTHON) $(MOZILLA_SRCDIR)/build/win32/pgomerge.py \
 	  $(PROGRAM:$(BIN_SUFFIX)=) $(DIST)/$(MOZ_APP_NAME)
 endif
 ifdef SHARED_LIBRARY
-	$(PYTHON) $(topsrcdir)/build/win32/pgomerge.py \
+	$(PYTHON) $(MOZILLA_SRCDIR)/build/win32/pgomerge.py \
 	  $(SHARED_LIBRARY_NAME) $(DIST)/$(MOZ_APP_NAME)
 endif
 endif # SHARED_LIBRARY || PROGRAM
======

And you will see two $(MOZ_APP_NAME) sit there.

That's mean pgomerge.py will find *.pgc inside dist/seamonkey.

And normally *.pgc will place inside dist/bin.

That's why pgo link phase got no data for optimize.

2. 
SHARED_LIBRARY defined wrong pgomerge.py path.

$(MOZILLA_SRCDIR)=$(topsrcdir)/mozilla

Please see above rules.mk.

Normally pgomerge.py will be placed here: 
comm-beta/mozilla/build/win32/pgomerge.py

so use $(topsrcdir) will got wrong path and will got error to stop compile session.

Comment 10

[[e-mail] (:bhearsum)]

I doubt we will ever do this. We have much, much higher confidence in our CI and build configuration these days, and alerts when performance changes by a notable amount.