Revert of Launch CFI for virtual calls on Linux x86-64.

Revert of Launch CFI for virtual calls on Linux x86-64. (patchset #2 id:20001 of https://codereview.chromium.org/2140373002/ )

Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions are within predicted upper bound, there're too many of them to ignore:

https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e58e616182522fd961d17ad648fc28f&start_rev=404312&end_rev=405943

We will need to reevaluate the reason for such consistent slowdown and will make another attempt after it's cleared.

Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
>
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
>
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
>
> The expected Perf impact by this CL:
>
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
>
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
>
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
>
> BUG=464797
>
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}

TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797
Committed: https://crrev.com/532a8777898abba488970f9dc17a067c7c517432
Cr-Commit-Position: refs/heads/master@{#405944}

[krasin1, 2016-07-16 17:58:27]

The CQ bit was checked by krasin@chromium.org

[krasin1, 2016-07-16 17:58:27]

Created Revert of Launch CFI for virtual calls on Linux x86-64.

[commit-bot: I haz the power, 2016-07-16 17:58:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-16 17:59:14]

Description was changed from

==========
Revert of Launch CFI for virtual calls on Linux x86-64. (patchset #2 id:20001 of
https://codereview.chromium.org/2140373002/ )

Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions
are within predicted upper bound, there're too many of them to ignore:

https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e5...

We will need to reevaluate the reason for such consistent slowdown and will make
another attempt after it's cleared.

Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
> 
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
> 
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
> 
> The expected Perf impact by this CL:
> 
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
> 
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
> 
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
> 
> BUG=464797
> 
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}

TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797
==========

to

==========
Revert of Launch CFI for virtual calls on Linux x86-64. (patchset #2 id:20001 of
https://codereview.chromium.org/2140373002/ )

Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions
are within predicted upper bound, there're too many of them to ignore:

https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e5...

We will need to reevaluate the reason for such consistent slowdown and will make
another attempt after it's cleared.

Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
> 
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
> 
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
> 
> The expected Perf impact by this CL:
> 
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
> 
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
> 
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
> 
> BUG=464797
> 
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}

TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797
==========

[commit-bot: I haz the power, 2016-07-16 17:59:15]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-16 18:01:12]

Description was changed from

==========
Revert of Launch CFI for virtual calls on Linux x86-64. (patchset #2 id:20001 of
https://codereview.chromium.org/2140373002/ )

Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions
are within predicted upper bound, there're too many of them to ignore:

https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e5...

We will need to reevaluate the reason for such consistent slowdown and will make
another attempt after it's cleared.

Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
> 
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
> 
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
> 
> The expected Perf impact by this CL:
> 
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
> 
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
> 
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
> 
> BUG=464797
> 
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}

TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797
==========

to

==========
Revert of Launch CFI for virtual calls on Linux x86-64. (patchset #2 id:20001 of
https://codereview.chromium.org/2140373002/ )

Reason for revert:
Too many blink_perf.layout benchmarks regressed by ~3.5%. While the regressions
are within predicted upper bound, there're too many of them to ignore:

https://chromeperf.appspot.com/report?sid=ebf0165d8c96c7a70c790d179a9bdc1f9e5...

We will need to reevaluate the reason for such consistent slowdown and will make
another attempt after it's cleared.

Original issue's description:
> Launch CFI for virtual calls on Linux x86-64.
>
> This is the second incremental step towards the full CFI launch.
> In the first step, we enabled LinkTimeOptimization (LTO) for the
> official Chrome builds. In this step we add Control Flow Integrity
> checks for all virtual calls.
>
> The remaining part is to add bad-cast checks to ensure the forward-edge
> Control Flow Integrity works as planned. That remaining part will
> require more work on reducing the overhead for size and speed by these
> CFI checks, so we don't enable them right away.
>
> The expected Perf impact by this CL:
>
> - Chrome binary size is increased by 5%,
> - Some of the benchmarks are slowed down by up to 3.5%.
>
> Note that before making it slower, we made it faster by implementing
> virtual const propagation and a number of heuristics for automatic
> devirtualization in LLVM which sped up some layout benchmarks by up to 7%
> (see https://crbug.com/580389 and https://crbug.com/617283)
>
> If there's a higher (negative) impact, we'll be willing to roll this
> feature back, but please allow the Perf bots to work for a day or two
> to collect more detailed statistics on the regressions, as it will help
> us to identify ways to speed it up (most likely, by inventing new ways
> for automatic devirtualization).
>
> BUG=464797
>
> Committed: https://crrev.com/01f474c48200a1e556a4cf668e2b5dbda0f38a6f
> Cr-Commit-Position: refs/heads/master@{#405894}

TBR=thakis@chromium.org,esprehn@chromium.org,krasin@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=464797

Committed: https://crrev.com/532a8777898abba488970f9dc17a067c7c517432
Cr-Commit-Position: refs/heads/master@{#405944}
==========

[commit-bot: I haz the power, 2016-07-16 18:01:13]

Patchset 1 (id:??) landed as
https://crrev.com/532a8777898abba488970f9dc17a067c7c517432
Cr-Commit-Position: refs/heads/master@{#405944}