SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
; RUN: opt < %s -sample-profile -sample-profile-file=%S/Inputs/branch.prof | opt -analyze -branch-prob | FileCheck %s
|
|
|
|
|
|
|
|
|
|
; Original C++ code for this test case:
|
|
|
|
|
;
|
|
|
|
|
; #include <stdio.h>
|
|
|
|
|
; #include <stdlib.h>
|
2015-10-01 08:26:56 +08:00
|
|
|
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
; int main(int argc, char *argv[]) {
|
|
|
|
|
; if (argc < 2)
|
|
|
|
|
; return 1;
|
|
|
|
|
; double result;
|
|
|
|
|
; int limit = atoi(argv[1]);
|
|
|
|
|
; if (limit > 100) {
|
2015-10-01 08:26:56 +08:00
|
|
|
; double s = 23.041968 * atoi(argv[2]);
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
; for (int u = 0; u < limit; u++) {
|
|
|
|
|
; double x = s;
|
|
|
|
|
; s = x + 3.049 + (double)u;
|
|
|
|
|
; s -= s + 3.94 / x * 0.32;
|
|
|
|
|
; }
|
|
|
|
|
; result = s;
|
|
|
|
|
; } else {
|
2015-10-01 08:26:56 +08:00
|
|
|
; result = atoi(argv[2]);
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
; }
|
|
|
|
|
; printf("result is %lf\n", result);
|
|
|
|
|
; return 0;
|
|
|
|
|
; }
|
|
|
|
|
|
|
|
|
|
@.str = private unnamed_addr constant [15 x i8] c"result is %lf\0A\00", align 1
|
|
|
|
|
|
2015-10-01 08:26:56 +08:00
|
|
|
; Function Attrs: uwtable
|
2015-11-06 06:03:56 +08:00
|
|
|
define i32 @main(i32 %argc, i8** %argv) #0 !dbg !6 {
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
; CHECK: Printing analysis 'Branch Probability Analysis' for function 'main':
|
|
|
|
|
|
|
|
|
|
entry:
|
2015-10-01 08:26:56 +08:00
|
|
|
%retval = alloca i32, align 4
|
|
|
|
|
%argc.addr = alloca i32, align 4
|
|
|
|
|
%argv.addr = alloca i8**, align 8
|
|
|
|
|
%result = alloca double, align 8
|
|
|
|
|
%limit = alloca i32, align 4
|
|
|
|
|
%s = alloca double, align 8
|
|
|
|
|
%u = alloca i32, align 4
|
|
|
|
|
%x = alloca double, align 8
|
|
|
|
|
store i32 0, i32* %retval, align 4
|
|
|
|
|
store i32 %argc, i32* %argc.addr, align 4
|
|
|
|
|
call void @llvm.dbg.declare(metadata i32* %argc.addr, metadata !16, metadata !17), !dbg !18
|
|
|
|
|
store i8** %argv, i8*** %argv.addr, align 8
|
|
|
|
|
call void @llvm.dbg.declare(metadata i8*** %argv.addr, metadata !19, metadata !17), !dbg !20
|
|
|
|
|
%0 = load i32, i32* %argc.addr, align 4, !dbg !21
|
|
|
|
|
%cmp = icmp slt i32 %0, 2, !dbg !23
|
|
|
|
|
br i1 %cmp, label %if.then, label %if.end, !dbg !24
|
|
|
|
|
; CHECK: edge entry -> if.then probability is 0x4ccccccd / 0x80000000 = 60.00%
|
|
|
|
|
; CHECK: edge entry -> if.end probability is 0x33333333 / 0x80000000 = 40.00%
|
|
|
|
|
|
|
|
|
|
if.then: ; preds = %entry
|
|
|
|
|
store i32 1, i32* %retval, align 4, !dbg !25
|
|
|
|
|
br label %return, !dbg !25
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
|
|
|
|
if.end: ; preds = %entry
|
2015-10-01 08:26:56 +08:00
|
|
|
call void @llvm.dbg.declare(metadata double* %result, metadata !26, metadata !17), !dbg !27
|
|
|
|
|
call void @llvm.dbg.declare(metadata i32* %limit, metadata !28, metadata !17), !dbg !29
|
|
|
|
|
%1 = load i8**, i8*** %argv.addr, align 8, !dbg !30
|
|
|
|
|
%arrayidx = getelementptr inbounds i8*, i8** %1, i64 1, !dbg !30
|
|
|
|
|
%2 = load i8*, i8** %arrayidx, align 8, !dbg !30
|
|
|
|
|
%call = call i32 @atoi(i8* %2) #4, !dbg !31
|
|
|
|
|
store i32 %call, i32* %limit, align 4, !dbg !29
|
|
|
|
|
%3 = load i32, i32* %limit, align 4, !dbg !32
|
|
|
|
|
%cmp1 = icmp sgt i32 %3, 100, !dbg !34
|
|
|
|
|
br i1 %cmp1, label %if.then.2, label %if.else, !dbg !35
|
|
|
|
|
; CHECK: edge if.end -> if.then.2 probability is 0x66666666 / 0x80000000 = 80.00%
|
|
|
|
|
; CHECK: edge if.end -> if.else probability is 0x1999999a / 0x80000000 = 20.00%
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
2015-10-01 08:26:56 +08:00
|
|
|
if.then.2: ; preds = %if.end
|
|
|
|
|
call void @llvm.dbg.declare(metadata double* %s, metadata !36, metadata !17), !dbg !38
|
|
|
|
|
%4 = load i8**, i8*** %argv.addr, align 8, !dbg !39
|
|
|
|
|
%arrayidx3 = getelementptr inbounds i8*, i8** %4, i64 2, !dbg !39
|
|
|
|
|
%5 = load i8*, i8** %arrayidx3, align 8, !dbg !39
|
|
|
|
|
%call4 = call i32 @atoi(i8* %5) #4, !dbg !40
|
|
|
|
|
%conv = sitofp i32 %call4 to double, !dbg !40
|
|
|
|
|
%mul = fmul double 0x40370ABE6A337A81, %conv, !dbg !41
|
|
|
|
|
store double %mul, double* %s, align 8, !dbg !38
|
|
|
|
|
call void @llvm.dbg.declare(metadata i32* %u, metadata !42, metadata !17), !dbg !44
|
|
|
|
|
store i32 0, i32* %u, align 4, !dbg !44
|
|
|
|
|
br label %for.cond, !dbg !45
|
|
|
|
|
|
|
|
|
|
for.cond: ; preds = %for.inc, %if.then.2
|
|
|
|
|
%6 = load i32, i32* %u, align 4, !dbg !46
|
|
|
|
|
%7 = load i32, i32* %limit, align 4, !dbg !48
|
|
|
|
|
%cmp5 = icmp slt i32 %6, %7, !dbg !49
|
|
|
|
|
br i1 %cmp5, label %for.body, label %for.end, !dbg !50
|
|
|
|
|
|
|
|
|
|
for.body: ; preds = %for.cond
|
|
|
|
|
call void @llvm.dbg.declare(metadata double* %x, metadata !51, metadata !17), !dbg !53
|
|
|
|
|
%8 = load double, double* %s, align 8, !dbg !54
|
|
|
|
|
store double %8, double* %x, align 8, !dbg !53
|
|
|
|
|
%9 = load double, double* %x, align 8, !dbg !55
|
|
|
|
|
%add = fadd double %9, 3.049000e+00, !dbg !56
|
|
|
|
|
%10 = load i32, i32* %u, align 4, !dbg !57
|
|
|
|
|
%conv6 = sitofp i32 %10 to double, !dbg !57
|
|
|
|
|
%add7 = fadd double %add, %conv6, !dbg !58
|
|
|
|
|
store double %add7, double* %s, align 8, !dbg !59
|
|
|
|
|
%11 = load double, double* %s, align 8, !dbg !60
|
|
|
|
|
%12 = load double, double* %x, align 8, !dbg !61
|
|
|
|
|
%div = fdiv double 3.940000e+00, %12, !dbg !62
|
|
|
|
|
%mul8 = fmul double %div, 3.200000e-01, !dbg !63
|
|
|
|
|
%add9 = fadd double %11, %mul8, !dbg !64
|
|
|
|
|
%13 = load double, double* %s, align 8, !dbg !65
|
|
|
|
|
%sub = fsub double %13, %add9, !dbg !65
|
|
|
|
|
store double %sub, double* %s, align 8, !dbg !65
|
|
|
|
|
br label %for.inc, !dbg !66
|
|
|
|
|
|
|
|
|
|
for.inc: ; preds = %for.body
|
|
|
|
|
%14 = load i32, i32* %u, align 4, !dbg !67
|
|
|
|
|
%inc = add nsw i32 %14, 1, !dbg !67
|
|
|
|
|
store i32 %inc, i32* %u, align 4, !dbg !67
|
|
|
|
|
br label %for.cond, !dbg !68
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
2015-10-01 08:26:56 +08:00
|
|
|
for.end: ; preds = %for.cond
|
|
|
|
|
%15 = load double, double* %s, align 8, !dbg !69
|
|
|
|
|
store double %15, double* %result, align 8, !dbg !70
|
|
|
|
|
br label %if.end.13, !dbg !71
|
|
|
|
|
|
|
|
|
|
if.else: ; preds = %if.end
|
|
|
|
|
%16 = load i8**, i8*** %argv.addr, align 8, !dbg !72
|
|
|
|
|
%arrayidx10 = getelementptr inbounds i8*, i8** %16, i64 2, !dbg !72
|
|
|
|
|
%17 = load i8*, i8** %arrayidx10, align 8, !dbg !72
|
|
|
|
|
%call11 = call i32 @atoi(i8* %17) #4, !dbg !74
|
|
|
|
|
%conv12 = sitofp i32 %call11 to double, !dbg !74
|
|
|
|
|
store double %conv12, double* %result, align 8, !dbg !75
|
|
|
|
|
br label %if.end.13
|
|
|
|
|
|
|
|
|
|
if.end.13: ; preds = %if.else, %for.end
|
|
|
|
|
%18 = load double, double* %result, align 8, !dbg !76
|
|
|
|
|
%call14 = call i32 (i8*, ...) @printf(i8* getelementptr inbounds ([15 x i8], [15 x i8]* @.str, i32 0, i32 0), double %18), !dbg !77
|
|
|
|
|
store i32 0, i32* %retval, align 4, !dbg !78
|
|
|
|
|
br label %return, !dbg !78
|
|
|
|
|
|
|
|
|
|
return: ; preds = %if.end.13, %if.then
|
|
|
|
|
%19 = load i32, i32* %retval, align 4, !dbg !79
|
|
|
|
|
ret i32 %19, !dbg !79
|
|
|
|
|
}
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
|
|
|
|
; Function Attrs: nounwind readnone
|
2015-10-01 08:26:56 +08:00
|
|
|
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
|
|
|
|
|
|
|
|
|
|
; Function Attrs: nounwind readonly
|
|
|
|
|
declare i32 @atoi(i8*) #2
|
|
|
|
|
|
|
|
|
|
declare i32 @printf(i8*, ...) #3
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
2015-10-01 08:26:56 +08:00
|
|
|
attributes #0 = { uwtable "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+sse,+sse2" "unsafe-fp-math"="false" "use-soft-float"="false" }
|
|
|
|
|
attributes #1 = { nounwind readnone }
|
|
|
|
|
attributes #2 = { nounwind readonly "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+sse,+sse2" "unsafe-fp-math"="false" "use-soft-float"="false" }
|
|
|
|
|
attributes #3 = { "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+sse,+sse2" "unsafe-fp-math"="false" "use-soft-float"="false" }
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
attributes #4 = { nounwind readonly }
|
|
|
|
|
|
|
|
|
|
!llvm.dbg.cu = !{!0}
|
2015-10-01 08:26:56 +08:00
|
|
|
!llvm.module.flags = !{!13, !14}
|
|
|
|
|
!llvm.ident = !{!15}
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
llvm-svn: 194566
2013-11-13 20:22:21 +08:00
|
|
|
|
2015-10-01 08:26:56 +08:00
|
|
|
!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !1, producer: "clang version 3.8.0 (trunk 248211) (llvm/trunk 248217)", isOptimized: false, runtimeVersion: 0, emissionKind: 1, enums: !2, retainedTypes: !3, subprograms: !5)
|
|
|
|
|
!1 = !DIFile(filename: "test.cc", directory: "/ssd/llvm_commit")
|
2015-03-28 04:46:33 +08:00
|
|
|
!2 = !{}
|
IR: Make metadata typeless in assembly
Now that `Metadata` is typeless, reflect that in the assembly. These
are the matching assembly changes for the metadata/value split in
r223802.
- Only use the `metadata` type when referencing metadata from a call
intrinsic -- i.e., only when it's used as a `Value`.
- Stop pretending that `ValueAsMetadata` is wrapped in an `MDNode`
when referencing it from call intrinsics.
So, assembly like this:
define @foo(i32 %v) {
call void @llvm.foo(metadata !{i32 %v}, metadata !0)
call void @llvm.foo(metadata !{i32 7}, metadata !0)
call void @llvm.foo(metadata !1, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{metadata !3}, metadata !0)
ret void, !bar !2
}
!0 = metadata !{metadata !2}
!1 = metadata !{i32* @global}
!2 = metadata !{metadata !3}
!3 = metadata !{}
turns into this:
define @foo(i32 %v) {
call void @llvm.foo(metadata i32 %v, metadata !0)
call void @llvm.foo(metadata i32 7, metadata !0)
call void @llvm.foo(metadata i32* @global, metadata !0)
call void @llvm.foo(metadata !3, metadata !0)
call void @llvm.foo(metadata !{!3}, metadata !0)
ret void, !bar !2
}
!0 = !{!2}
!1 = !{i32* @global}
!2 = !{!3}
!3 = !{}
I wrote an upgrade script that handled almost all of the tests in llvm
and many of the tests in cfe (even handling many `CHECK` lines). I've
attached it (or will attach it in a moment if you're speedy) to PR21532
to help everyone update their out-of-tree testcases.
This is part of PR21532.
llvm-svn: 224257
2014-12-16 03:07:53 +08:00
|
|
|
!3 = !{!4}
|
2015-10-01 08:26:56 +08:00
|
|
|
!4 = !DIBasicType(name: "double", size: 64, align: 64, encoding: DW_ATE_float)
|
|
|
|
|
!5 = !{!6}
|
2015-11-06 06:03:56 +08:00
|
|
|
!6 = distinct !DISubprogram(name: "main", scope: !1, file: !1, line: 4, type: !7, isLocal: false, isDefinition: true, scopeLine: 4, flags: DIFlagPrototyped, isOptimized: false, variables: !2)
|
2015-10-01 08:26:56 +08:00
|
|
|
!7 = !DISubroutineType(types: !8)
|
|
|
|
|
!8 = !{!9, !9, !10}
|
|
|
|
|
!9 = !DIBasicType(name: "int", size: 32, align: 32, encoding: DW_ATE_signed)
|
|
|
|
|
!10 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64, align: 64)
|
|
|
|
|
!11 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !12, size: 64, align: 64)
|
|
|
|
|
!12 = !DIBasicType(name: "char", size: 8, align: 8, encoding: DW_ATE_signed_char)
|
|
|
|
|
!13 = !{i32 2, !"Dwarf Version", i32 4}
|
|
|
|
|
!14 = !{i32 2, !"Debug Info Version", i32 3}
|
|
|
|
|
!15 = !{!"clang version 3.8.0 (trunk 248211) (llvm/trunk 248217)"}
|
|
|
|
|
!16 = !DILocalVariable(name: "argc", arg: 1, scope: !6, file: !1, line: 4, type: !9)
|
|
|
|
|
!17 = !DIExpression()
|
|
|
|
|
!18 = !DILocation(line: 4, column: 15, scope: !6)
|
|
|
|
|
!19 = !DILocalVariable(name: "argv", arg: 2, scope: !6, file: !1, line: 4, type: !10)
|
|
|
|
|
!20 = !DILocation(line: 4, column: 27, scope: !6)
|
|
|
|
|
!21 = !DILocation(line: 5, column: 8, scope: !22)
|
|
|
|
|
!22 = distinct !DILexicalBlock(scope: !6, file: !1, line: 5, column: 8)
|
|
|
|
|
!23 = !DILocation(line: 5, column: 13, scope: !22)
|
|
|
|
|
!24 = !DILocation(line: 5, column: 8, scope: !6)
|
|
|
|
|
!25 = !DILocation(line: 6, column: 6, scope: !22)
|
|
|
|
|
!26 = !DILocalVariable(name: "result", scope: !6, file: !1, line: 7, type: !4)
|
|
|
|
|
!27 = !DILocation(line: 7, column: 11, scope: !6)
|
|
|
|
|
!28 = !DILocalVariable(name: "limit", scope: !6, file: !1, line: 8, type: !9)
|
|
|
|
|
!29 = !DILocation(line: 8, column: 8, scope: !6)
|
|
|
|
|
!30 = !DILocation(line: 8, column: 21, scope: !6)
|
|
|
|
|
!31 = !DILocation(line: 8, column: 16, scope: !6)
|
|
|
|
|
!32 = !DILocation(line: 9, column: 8, scope: !33)
|
|
|
|
|
!33 = distinct !DILexicalBlock(scope: !6, file: !1, line: 9, column: 8)
|
|
|
|
|
!34 = !DILocation(line: 9, column: 14, scope: !33)
|
|
|
|
|
!35 = !DILocation(line: 9, column: 8, scope: !6)
|
|
|
|
|
!36 = !DILocalVariable(name: "s", scope: !37, file: !1, line: 10, type: !4)
|
|
|
|
|
!37 = distinct !DILexicalBlock(scope: !33, file: !1, line: 9, column: 21)
|
|
|
|
|
!38 = !DILocation(line: 10, column: 13, scope: !37)
|
|
|
|
|
!39 = !DILocation(line: 10, column: 34, scope: !37)
|
|
|
|
|
!40 = !DILocation(line: 10, column: 29, scope: !37)
|
|
|
|
|
!41 = !DILocation(line: 10, column: 27, scope: !37)
|
|
|
|
|
!42 = !DILocalVariable(name: "u", scope: !43, file: !1, line: 11, type: !9)
|
|
|
|
|
!43 = distinct !DILexicalBlock(scope: !37, file: !1, line: 11, column: 6)
|
|
|
|
|
!44 = !DILocation(line: 11, column: 15, scope: !43)
|
|
|
|
|
!45 = !DILocation(line: 11, column: 11, scope: !43)
|
|
|
|
|
!46 = !DILocation(line: 11, column: 22, scope: !47)
|
|
|
|
|
!47 = distinct !DILexicalBlock(scope: !43, file: !1, line: 11, column: 6)
|
|
|
|
|
!48 = !DILocation(line: 11, column: 26, scope: !47)
|
|
|
|
|
!49 = !DILocation(line: 11, column: 24, scope: !47)
|
|
|
|
|
!50 = !DILocation(line: 11, column: 6, scope: !43)
|
|
|
|
|
!51 = !DILocalVariable(name: "x", scope: !52, file: !1, line: 12, type: !4)
|
|
|
|
|
!52 = distinct !DILexicalBlock(scope: !47, file: !1, line: 11, column: 38)
|
|
|
|
|
!53 = !DILocation(line: 12, column: 15, scope: !52)
|
|
|
|
|
!54 = !DILocation(line: 12, column: 19, scope: !52)
|
|
|
|
|
!55 = !DILocation(line: 13, column: 12, scope: !52)
|
|
|
|
|
!56 = !DILocation(line: 13, column: 14, scope: !52)
|
|
|
|
|
!57 = !DILocation(line: 13, column: 32, scope: !52)
|
|
|
|
|
!58 = !DILocation(line: 13, column: 22, scope: !52)
|
|
|
|
|
!59 = !DILocation(line: 13, column: 10, scope: !52)
|
|
|
|
|
!60 = !DILocation(line: 14, column: 13, scope: !52)
|
|
|
|
|
!61 = !DILocation(line: 14, column: 24, scope: !52)
|
|
|
|
|
!62 = !DILocation(line: 14, column: 22, scope: !52)
|
|
|
|
|
!63 = !DILocation(line: 14, column: 26, scope: !52)
|
|
|
|
|
!64 = !DILocation(line: 14, column: 15, scope: !52)
|
|
|
|
|
!65 = !DILocation(line: 14, column: 10, scope: !52)
|
|
|
|
|
!66 = !DILocation(line: 15, column: 6, scope: !52)
|
|
|
|
|
!67 = !DILocation(line: 11, column: 34, scope: !47)
|
|
|
|
|
!68 = !DILocation(line: 11, column: 6, scope: !47)
|
|
|
|
|
!69 = !DILocation(line: 16, column: 15, scope: !37)
|
|
|
|
|
!70 = !DILocation(line: 16, column: 13, scope: !37)
|
|
|
|
|
!71 = !DILocation(line: 17, column: 4, scope: !37)
|
|
|
|
|
!72 = !DILocation(line: 18, column: 20, scope: !73)
|
|
|
|
|
!73 = distinct !DILexicalBlock(scope: !33, file: !1, line: 17, column: 11)
|
|
|
|
|
!74 = !DILocation(line: 18, column: 15, scope: !73)
|
|
|
|
|
!75 = !DILocation(line: 18, column: 13, scope: !73)
|
|
|
|
|
!76 = !DILocation(line: 20, column: 30, scope: !6)
|
|
|
|
|
!77 = !DILocation(line: 20, column: 4, scope: !6)
|
|
|
|
|
!78 = !DILocation(line: 21, column: 4, scope: !6)
|
|
|
|
|
!79 = !DILocation(line: 22, column: 2, scope: !6)
|