All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=696992

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpJKJqwsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgxNHM8wkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgxJHptQsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpNbaogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpLLmrAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgxN-BqwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpJTb-AgM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgIDgpLL8tQoM


Bot(s) for this bug's original alert(s):

webrtc-mac-large-tests

It indeed seems the roll is causing this problem.
Can you try this?
1. run webrtc_perf_tests  on your machine. Make note of the value of one of the metrics showing up here.
2. Revert the Clang roll locally, essentially by just:
cd src/tools
git revert edfe48e975a7549b3eb79407a1b0f4daab64cdbe
3. gclient sync
4. compile
5. Re-run webrtc_perf_tests and compare the metric noted in 1.

Does it still regress? Then it's not the Clang roll that caused this. I think we should find that out before proceeding.

I've tried what you suggested, but I'm unable to say anything interesting. The metrics in the bug are from H264 on Mac, and the H264 tests don't appear to be running at all on my Linux machine. Is there a way to force them to run?

The encode times in some other tests have changed slightly, but it is impossible to tell whether that is a real change or just random variation. Note that the difference in the bug is small as well; for example the encode usage increased from 20.2% to 20.7% in foreman_cif_delay_50_0_plr_5_H264.

Since this regression only happens on Mac you have to run it on a Mac.

I checked the graphs all the way up to today's date and it seems the regression is still around, but I leaning towards accepting that one and close this bug. 
I'll leave that decision to you though - you might want to check with someone like holmer@ before closing it.