This should in principle be possible. Clang has a concept of "hidden LTO visibility" [0] which essentially controls whether we may emit CFI checks for a particular class. What we would need to do in the case where CFI and CFG are both enabled is emit CFG checks for classes without hidden LTO visibility.

[0] http://clang.llvm.org/docs/LTOVisibility.html

(Since kcc apparently was confused by this: We do use /guard:cf today, it was enabled in https://codereview.chromium.org/2412983006)

This confuses me even more :) 
Do we use CFG on the entire chrome, or we just enabled it at link time but
did not actually instrument the code? 

If we do instrument all the code, do we have any performance and code size
numbers? 

From my reading of https://codereview.chromium.org/2412983006/ we instrument only the handful of cc files that are directly part of chrome_initial and chrome_elf, so we don't use it for most of the code. Ah yes, https://codereview.chromium.org/2412983006/#msg11 says the same (also talks about binary size and whatnot). It looks like we didn't turn it on more than that since (https://cs.chromium.org/search/?q=win_msvc_cfg&sq=package:chromium&type=cs).

So we use it a bit, but not much, as far as I can tell. cc'ing folks who know better.

#4 is currently accurate.  I have CLs underway to add support for dynamically adding addresses to the valid function call table at run time.  This is required to instrument most of chrome - due to our hooking.

Also, note that Return Flow Guard will soon be enabled and released by MS.  That will be accessible through the same "/guard:x" compile and link arguments.

Some other relevant research: as part of the investigation of fixes for  crbug.com/766236  (longjmp crashes) I measured the binary-size cost of compiling all of Chromium with /guard:cf. Comment #10 has the details (and links to a CL) but the summary is that I saw 3.0% and 3.9% increases in binary size for chrome_child.dll and chrome.dll, 64-bit release builds.

Archiving P3s older than 1 year with no owner or component.