This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Fwd: failure notice
- From: Uday Khedker <uday at cse dot iitb dot ac dot in>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 19 Aug 2013 15:14:03 +0530
- Subject: Fwd: failure notice
- References: <9E dot CF dot 14831 dot 286E1125 at mailrly1 dot iitb dot ac dot in>
Hi Ilya,
Let me respond to your first question. I am not so much well versed with
the requirements of the second question.
Yes, your conclusions are correct. You can find some more details in
slides 39/62 to 61/62 in
http://www.cse.iitb.ac.in/grc/gcc-workshop-13/downloads/slides/Day2/gccw13-code-view.pdf.
Thanks and regards,
Dr. Uday Khedker
Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
Email : uday@cse.iitb.ac.in
Homepage: http://www.cse.iitb.ac.in/~uday
Phone :
Office - 91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct)
Res. - 91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
On Thursday 15 August 2013 07:06 PM, Ilya Verbin wrote:
Hi All,
I'm trying to figure out how LTO infrastructure works on a high level.
I want to make sure that I understand this correctly. Could you please
help me with that?
1. Execution flow. As far as I understood, there are 2 modes of
operation - with/without LTO plugin. Below are the execution flows
for each mode.
Without LTO plugin:
gcc -flto # Call GCC driver
|_ cc1 # Compile first source file into asm + intermediate language
|_ as # Assemble these asm + IL into temporary object file
|_ ... # Compile and assemble all remaining source files
|_ collect2 # Call linker driver
|_ lto-wrapper # Call lto-wrapper directly from collect2
| |_ gcc # Driver
| | |_ lto1 # Perform WPA and split into partitions
| |_ gcc # Driver
| | |_ lto1 # Perform LTRANS for the first partition
| | |_ as # Assemble this partition into final object file
| |_ ... # Perform LTRANS for each partition
|_ collect-ld # Simple wrapper over ld
|_ ld # Perform linking
Using LTO plugin:
gcc -flto # Call GCC driver
|_ cc1 # Compile first source file into asm + intermediate language
|_ as # Assemble these asm + IL into temporary object file
|_ ... # Compile and assemble all remaining source files
|_ collect2 # Call linker driver
|_ collect-ld # Simple wrapper over ld
|_ ld with liblto_plugin.so # Perform LTO and linking
|_ lto-wrapper # Is called from liblto_plugin.so
|_ gcc # Driver
| |_ lto1 # Perform WPA and split into partitions
|_ gcc # Driver
| |_ lto1 # Perform LTRANS for the first partition
| |_ as # Assemble this partition into final object file
|_ ... # Perform LTRANS for each partition
Are they correct?
2. The second question, regarding #pragma omp target implementation.
I'm going to reuse LTO approach in a prototype, that will produce 2
binaries - for host and target architectures. Target binary will contain
functions outlined from omp target region and some infrastructure to run
them.
To produce 2 binaries we need to run gcc and ld twice. At the first run
gcc will generate object file, that contains optimized code for host and
GIMPLE for target. At the second run gcc will read the GIMPLE and
generate optimized code for target.
So, the question is - what is the right place for the second run of gcc
and ld? Should I insert them into liblto_plugin.so? Or should I create
entirely new plugin, that will only call gcc and ld for target, without
performing any LTO optimizations for host?
Suggestions?
----
Thanks,
Ilya Verbin,
Software Engineer
Intel Corporation
--------------010105060304040106080107
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Ilya,<br>
<br>
Let me respond to your first question. I am not so much well
versed with the requirements of the second question.<br>
<br>
Yes, your conclusions are correct. You can find some more details
in slides 39/62 to 61/62 in
<a class="moz-txt-link-freetext"
href="http://www.cse.iitb.ac.in/grc/gcc-workshop-13/downloads/slides/Day2/gccw13-code-view.pdf";>http://www.cse.iitb.ac.in/grc/gcc-workshop-13/downloads/slides/Day2/gccw13-code-view.pdf</a>.<br>
<br>
Thanks and regards,<br>
<br>
Uday.<br>
<br>
<div class="moz-signature">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title>signature.html</title>
<table style="text-align: left; color: rgb(153, 153, 153);"
border="1" bordercolor="lightgray" cellpadding="2"
cellspacing="0">
<tbody>
<tr>
<td style="vertical-align: top; width: 365px;"><span
style="color: rgb(153, 153, 153);"></span>
<table style="text-align: left; width: 100%;" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="vertical-align: top; white-space:
nowrap;"><span style="color: rgb(153, 153,
153);">Dr. Uday Khedker</span></td>
</tr>
<tr>
<td style="vertical-align: top; white-space:
nowrap;"><span style="color: rgb(153, 153,
153);">Professor</span></td>
</tr>
<tr>
<td style="vertical-align: top; white-space:
nowrap;"><span style="color: rgb(153, 153,
153);">Department
of Computer Science & Engg.</span></td>
</tr>
<tr>
<td style="vertical-align: top; white-space:
nowrap;"><span style="color: rgb(153, 153,
153);">IIT Bombay,
Powai, Mumbai 400 076, India.</span></td>
</tr>
</tbody>
</table>
<span style="color: rgb(153, 153, 153);"> </span></td>
<td style="vertical-align: top; color: rgb(153, 153, 153);
width: 595px;">
<table style="text-align: left; width: 595px;
margin-left: auto; margin-right: 0px;" border="0"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="vertical-align: top; color: rgb(153,
153, 153);">Email
:</td>
<td style="vertical-align: top; color: rgb(153,
153, 153);"><a class="moz-txt-link-abbreviated"
href="mailto:uday@cse.iitb.ac.in";>uday@cse.iitb.ac.in</a></td>
</tr>
<tr>
<td style="vertical-align: top;"><span
style="color: rgb(153, 153,
153);">Homepage:</span>
</td>
<td style="vertical-align: top; color: rgb(153,
153, 153);"><a class="moz-txt-link-freetext"
href="http://www.cse.iitb.ac.in/~uday";>http://www.cse.iitb.ac.in/~uday</a></td>
</tr>
<tr>
<td style="vertical-align: top; color: rgb(153,
153, 153);">Phone
: </td>
<td style="vertical-align: top;">
<table style="text-align: left; width: 100%;"
cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="vertical-align: top; color:
rgb(153, 153, 153);">Office - </td>
<td style="vertical-align: top;
text-align: left; color: rgb(153, 153,
153);">91
(22)
2572
2545
x
7717,
91
(22)
2576
7717
(Direct)</td>
</tr>
<tr>
<td style="vertical-align: top; color:
rgb(153, 153, 153);">Res.
- </td>
<td style="vertical-align: middle;
text-align: left; color: rgb(153, 153,
153);">91
(22)
2572
2545
x
8717,
91
(22)
2576
8717
(Direct)<br>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
<br style="color: rgb(153, 153, 153);">
<br>
</div>
On Thursday 15 August 2013 07:06 PM, Ilya Verbin wrote:<br>
</div>
<blockquote
cite="mid:20130815133639.GA42355@msticlxl57.ims.intel.com"
type="cite">
<pre wrap="">Hi All,
I'm trying to figure out how LTO infrastructure works on a high level.
I want to make sure that I understand this correctly. Could you please
help me with that?
1. Execution flow. As far as I understood, there are 2 modes of
operation - with/without LTO plugin. Below are the execution flows
for each mode.
Without LTO plugin:
gcc -flto # Call GCC driver
|_ cc1 # Compile first source file into asm + intermediate language
|_ as # Assemble these asm + IL into temporary object file
|_ ... # Compile and assemble all remaining source files
|_ collect2 # Call linker driver
|_ lto-wrapper # Call lto-wrapper directly from collect2
| |_ gcc # Driver
| | |_ lto1 # Perform WPA and split into partitions
| |_ gcc # Driver
| | |_ lto1 # Perform LTRANS for the first partition
| | |_ as # Assemble this partition into final object file
| |_ ... # Perform LTRANS for each partition
|_ collect-ld # Simple wrapper over ld
|_ ld # Perform linking
Using LTO plugin:
gcc -flto # Call GCC driver
|_ cc1 # Compile first source file into asm + intermediate language
|_ as # Assemble these asm + IL into temporary object file
|_ ... # Compile and assemble all remaining source files
|_ collect2 # Call linker driver
|_ collect-ld # Simple wrapper over ld
|_ ld with liblto_plugin.so # Perform LTO and linking
|_ lto-wrapper # Is called from liblto_plugin.so
|_ gcc # Driver
| |_ lto1 # Perform WPA and split into partitions
|_ gcc # Driver
| |_ lto1 # Perform LTRANS for the first partition
| |_ as # Assemble this partition into final
object file
|_ ... # Perform LTRANS for each partition
Are they correct?
2. The second question, regarding #pragma omp target implementation.
I'm going to reuse LTO approach in a prototype, that will produce 2
binaries - for host and target architectures. Target binary will contain
functions outlined from omp target region and some infrastructure to run
them.
To produce 2 binaries we need to run gcc and ld twice. At the first run
gcc will generate object file, that contains optimized code for host and
GIMPLE for target. At the second run gcc will read the GIMPLE and
generate optimized code for target.
So, the question is - what is the right place for the second run of gcc
and ld? Should I insert them into liblto_plugin.so? Or should I create
entirely new plugin, that will only call gcc and ld for target, without
performing any LTO optimizations for host?
Suggestions?
----
Thanks,
Ilya Verbin,
Software Engineer
Intel Corporation
</pre>
</blockquote>
<br>
</body>
</html>
--------------010105060304040106080107--