[turbofan] Print APIs are for debugging.

[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug
time, we cannot (easily) synthesize an output stream, hence the choice
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is
addressed by the changes in pipeline.cc, using the various operator<<,
and does not require the changes in instruction.{h|cc}, and the
generalization of the Print APIs.

BUG=

Committed: https://crrev.com/817a60cc8dc79161a59010e5fab5f126a9b057ab
Cr-Commit-Position: refs/heads/master@{#39190}

[Mircea Trofin, 2016-09-04 05:22:58]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-04 05:23:05]

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

[Mircea Trofin, 2016-09-04 05:24:17]

Description was changed from

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug time,
we cannot (easily) synthesize an output stream, hence the choice of directing
to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is addressed by the
changes
in pipeline.cc, using the various operator<<, and does not need the changes
in instruction.{h|cc}, and the generalization of the Print APIs.

BUG=
==========

to

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug 
time, we cannot (easily) synthesize an output stream, hence the choice 
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is 
addressed by the changes in pipeline.cc, using the various operator<<, 
and does not require the changes in instruction.{h|cc}, and the 
generalization of the Print APIs.

BUG=
==========

[Mircea Trofin, 2016-09-04 05:24:17]

mtrofin@chromium.org changed reviewers:
+ bmeurer@chromium.org, ofrobots@google.com

[Mircea Trofin, 2016-09-04 05:27:25]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-04 05:27:35]

Dry run: 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-09-04 05:54:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-04 05:54:38]

Dry run: This issue passed the CQ dry run.

[ofrobots, 2016-09-04 14:45:05]

On 2016/09/04 05:24:54, Mircea Trofin wrote:

[ofrobots, 2016-09-04 14:45:54]

On 2016/09/04 05:24:54, Mircea Trofin wrote:

The issue is that I want to be able to use turbo trace flags without getting any
trace output showing up on stdout. The changes to instruction.[h|cc] were
necessary to make this happen.

[Mircea Trofin, 2016-09-04 15:00:14]

On 2016/09/04 14:45:54, ofrobots wrote:
> On 2016/09/04 05:24:54, Mircea Trofin wrote:
> 
> The issue is that I want to be able to use turbo trace flags without getting
any
> trace output showing up on stdout. The changes to instruction.[h|cc] were
> necessary to make this happen.

I'm confused, where are those Print apis called from, when you use turbo trace
flags? 
Could you give me an exsmple command line? Thanks!

[Mircea Trofin, 2016-09-04 15:33:39]

On 2016/09/04 15:00:14, Mircea Trofin wrote:
> On 2016/09/04 14:45:54, ofrobots wrote:
> > On 2016/09/04 05:24:54, Mircea Trofin wrote:
> > 
> > The issue is that I want to be able to use turbo trace flags without getting
> any
> > trace output showing up on stdout. The changes to instruction.[h|cc] were
> > necessary to make this happen.
> 
> I'm confused, where are those Print apis called from, when you use turbo trace
> flags? 
> Could you give me an exsmple command line? Thanks!

Nevermind - I saw the problem (PrintBlock being called from operator<<).

Fix coming up.

[Mircea Trofin, 2016-09-04 15:57:42]

The CQ bit was checked by mtrofin@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-04 15:57:43]

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

[Mircea Trofin, 2016-09-04 15:59:30]

PTAL

Added an operator<< for PrintableInstructionBlocks (and the respective
structure)

This should address both tracing and debugging scenarios.

[commit-bot: I haz the power, 2016-09-04 16:20:28]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-04 16:20:29]

Dry run: This issue passed the CQ dry run.

[ofrobots, 2016-09-06 05:10:25]

On 2016/09/04 15:59:30, Mircea Trofin wrote:
> PTAL
> 
> Added an operator<< for PrintableInstructionBlocks (and the respective
> structure)
> 
> This should address both tracing and debugging scenarios.

This LGTM. I too have struggled with synthesizing the stdout OFStream, specially
on Mac. Would the following patch be an alternative way to solve the output
stream problem in the debugger:

diff --git a/src/log.cc b/src/log.cc
index fc7fcb9..a8027ec 100644
--- a/src/log.cc
+++ b/src/log.cc
@@ -37,6 +37,8 @@ static const char*
kLogEventsNames[CodeEventListener::NUMBER_OF_LOG_EVENTS] = {
     LOG_EVENTS_AND_TAGS_LIST(DECLARE_EVENT)};
 #undef DECLARE_EVENT

+const OFStream stdout_(stdout);
+
 static const char* ComputeMarker(SharedFunctionInfo* shared,
                                  AbstractCode* code) {
   switch (code->kind()) {

[Benedikt Meurer, 2016-09-06 05:20:37]

LGTM (rubber-stamped Ali's LGTM)

[Mircea Trofin, 2016-09-06 05:21:42]

The CQ bit was checked by mtrofin@chromium.org

[commit-bot: I haz the power, 2016-09-06 05:21:45]

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

[Mircea Trofin, 2016-09-06 05:27:43]

On 2016/09/06 05:10:25, ofrobots wrote:
> On 2016/09/04 15:59:30, Mircea Trofin wrote:
> > PTAL
> > 
> > Added an operator<< for PrintableInstructionBlocks (and the respective
> > structure)
> > 
> > This should address both tracing and debugging scenarios.
> 
> This LGTM. I too have struggled with synthesizing the stdout OFStream,
specially
> on Mac. Would the following patch be an alternative way to solve the output
> stream problem in the debugger:
> 
> diff --git a/src/log.cc b/src/log.cc
> index fc7fcb9..a8027ec 100644
> --- a/src/log.cc
> +++ b/src/log.cc
> @@ -37,6 +37,8 @@ static const char*
> kLogEventsNames[CodeEventListener::NUMBER_OF_LOG_EVENTS] = {
>      LOG_EVENTS_AND_TAGS_LIST(DECLARE_EVENT)};
>  #undef DECLARE_EVENT
> 
> +const OFStream stdout_(stdout);
> +
>  static const char* ComputeMarker(SharedFunctionInfo* shared,
>                                   AbstractCode* code) {
>    switch (code->kind()) {

Probably - we'd have to try it. The second problem I should have mentioned, with
the 
InstructionSequence model (and related - MoveOperands, all that) is this need
for the 
RegisterConfiguration. An alternative may be to have a ostream instance that
holds on 
to a RegisterConfiguration, possibly obtainable (the ostream instance) from 
RegisterAllocationData, or something like that. On the  other hand, all that
design may 
be a bit overkill. 

That aside, having a debug-time OFStream may be goodness in itself for
other scenarios!

[commit-bot: I haz the power, 2016-09-06 05:46:31]

Description was changed from

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug 
time, we cannot (easily) synthesize an output stream, hence the choice 
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is 
addressed by the changes in pipeline.cc, using the various operator<<, 
and does not require the changes in instruction.{h|cc}, and the 
generalization of the Print APIs.

BUG=
==========

to

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug 
time, we cannot (easily) synthesize an output stream, hence the choice 
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is 
addressed by the changes in pipeline.cc, using the various operator<<, 
and does not require the changes in instruction.{h|cc}, and the 
generalization of the Print APIs.

BUG=
==========

[commit-bot: I haz the power, 2016-09-06 05:46:32]

Committed patchset #3 (id:40001)

[commit-bot: I haz the power, 2016-09-06 05:47:26]

Description was changed from

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug 
time, we cannot (easily) synthesize an output stream, hence the choice 
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is 
addressed by the changes in pipeline.cc, using the various operator<<, 
and does not require the changes in instruction.{h|cc}, and the 
generalization of the Print APIs.

BUG=
==========

to

==========
[turbofan] Print APIs are for debugging.

The Print APIs on the instruction model are for debugging. At debug
time, we cannot (easily) synthesize an output stream, hence the choice
of directing to stdout in those APIs.

The concern in https://codereview.chromium.org/2293413004/ is
addressed by the changes in pipeline.cc, using the various operator<<,
and does not require the changes in instruction.{h|cc}, and the
generalization of the Print APIs.

BUG=

Committed: https://crrev.com/817a60cc8dc79161a59010e5fab5f126a9b057ab
Cr-Commit-Position: refs/heads/master@{#39190}
==========

[commit-bot: I haz the power, 2016-09-06 05:47:27]

Patchset 3 (id:??) landed as
https://crrev.com/817a60cc8dc79161a59010e5fab5f126a9b057ab
Cr-Commit-Position: refs/heads/master@{#39190}