<feed xmlns='http://www.w3.org/2005/Atom'>
<title>llvm-project.git/clang/lib/Driver/Tools.cpp, branch main</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/'/>
<entry>
<title>[Driver] Consolidate tools and toolchains by target platform. (NFC)</title>
<updated>2017-03-08T01:02:16+00:00</updated>
<author>
<name>David L. Jones</name>
<email>dlj@google.com</email>
</author>
<published>2017-03-08T01:02:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=f561abab56801665997217099e5652e625e81cb2'/>
<id>f561abab56801665997217099e5652e625e81cb2</id>
<content type='text'>
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)

This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.

There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.

I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.

There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.

Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar

Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30372

llvm-svn: 297250
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:
(This is a move-only refactoring patch. There are no functionality changes.)

This patch splits apart the Clang driver's tool and toolchain implementation
files. Each target platform toolchain is moved to its own file, along with the
closest-related tools. Each target platform toolchain has separate headers and
implementation files, so the hierarchy of classes is unchanged.

There are some remaining shared free functions, mostly from Tools.cpp. Several
of these move to their own architecture-specific files, similar to r296056. Some
of them are only used by a single target platform; since the tools and
toolchains are now together, some helpers now live in a platform-specific file.
The balance are helpers related to manipulating argument lists, so they are now
in a new file pair, CommonArgs.h and .cpp.

I've tried to cluster the code logically, which is fairly straightforward for
most of the target platforms and shared architectures. I think I've made
reasonable choices for these, as well as the various shared helpers; but of
course, I'm happy to hear feedback in the review.

There are some particular things I don't like about this patch, but haven't been
able to find a better overall solution. The first is the proliferation of files:
there are several files that are tiny because the toolchain is not very
different from its base (usually the Gnu tools/toolchain). I think this is
mostly a reflection of the true complexity, though, so it may not be "fixable"
in any reasonable sense. The second thing I don't like are the includes like
"../Something.h". I've avoided this largely by clustering into the current file
structure. However, a few of these includes remain, and in those cases it
doesn't make sense to me to sink an existing file any deeper.

Reviewers: rsmith, mehdi_amini, compnerd, rnk, javed.absar

Subscribers: emaste, jfb, danalbert, srhines, dschuff, jyknight, nemanjai, nhaehnle, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30372

llvm-svn: 297250
</pre>
</div>
</content>
</entry>
<entry>
<title>Add arch-specific directory to search path</title>
<updated>2017-03-03T23:20:49+00:00</updated>
<author>
<name>Pirama Arumuga Nainar</name>
<email>pirama@google.com</email>
</author>
<published>2017-03-03T23:20:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=65a16dd85811f385f36c8d94bb960d88dce9a6c9'/>
<id>65a16dd85811f385f36c8d94bb960d88dce9a6c9</id>
<content type='text'>
Summary:

This change adds an arch-specific subdirectory in &lt;ResourceDir&gt;/lib/&lt;OS&gt;
to the linker search path.  This path also gets added as '-rpath' for
native compilation if a runtime is linked in as a shared object.  This
allows arch-specific libraries to be installed alongside clang.

Reviewers: danalbert, cbergstrom, javed.absar

Subscribers: srhines

Differential Revision: https://reviews.llvm.org/D30015

llvm-svn: 296927
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary:

This change adds an arch-specific subdirectory in &lt;ResourceDir&gt;/lib/&lt;OS&gt;
to the linker search path.  This path also gets added as '-rpath' for
native compilation if a runtime is linked in as a shared object.  This
allows arch-specific libraries to be installed alongside clang.

Reviewers: danalbert, cbergstrom, javed.absar

Subscribers: srhines

Differential Revision: https://reviews.llvm.org/D30015

llvm-svn: 296927
</pre>
</div>
</content>
</entry>
<entry>
<title>[PowerPC] Enable -fomit-frame-pointer by default for PPC</title>
<updated>2017-03-03T09:49:17+00:00</updated>
<author>
<name>Nemanja Ivanovic</name>
<email>nemanja.i.ibm@gmail.com</email>
</author>
<published>2017-03-03T09:49:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e96e6972945774f96866220fe7569918346b34e5'/>
<id>e96e6972945774f96866220fe7569918346b34e5</id>
<content type='text'>
As is the case on platforms like Mips, X86 and SystemZ, the -fomit-frame-pointer
should be enabled by default on PPC when optimizing at -O1 and above. This
brings the behaviour of LLVM on PPC in line with GCC.

Committing on behalf of Hiroshi Inoue.

Differential Revision: https://reviews.llvm.org/D29750

llvm-svn: 296861
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As is the case on platforms like Mips, X86 and SystemZ, the -fomit-frame-pointer
should be enabled by default on PPC when optimizing at -O1 and above. This
brings the behaviour of LLVM on PPC in line with GCC.

Committing on behalf of Hiroshi Inoue.

Differential Revision: https://reviews.llvm.org/D29750

llvm-svn: 296861
</pre>
</div>
</content>
</entry>
<entry>
<title>Set ABIs correctly for OpenBSD/arm; soft float and aapcs-linux.</title>
<updated>2017-02-28T03:20:26+00:00</updated>
<author>
<name>Brad Smith</name>
<email>brad@comstyle.com</email>
</author>
<published>2017-02-28T03:20:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=3d648b357a1c1426bfe0bee402ddf1ce30cd3741'/>
<id>3d648b357a1c1426bfe0bee402ddf1ce30cd3741</id>
<content type='text'>
llvm-svn: 296430
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
llvm-svn: 296430
</pre>
</div>
</content>
</entry>
<entry>
<title>[Driver] Move architecture-specific free helper functions to their own files.</title>
<updated>2017-02-24T00:28:01+00:00</updated>
<author>
<name>David L. Jones</name>
<email>dlj@google.com</email>
</author>
<published>2017-02-24T00:28:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=ecc6de35fba933b1081a7847b3687f2e99b3e34c'/>
<id>ecc6de35fba933b1081a7847b3687f2e99b3e34c</id>
<content type='text'>
This patch moves helper functions that are CPU-specific out of Driver.cpp and to
separate implementation files. The new files are named for the architecture,
e.g. ARMArch.cpp.

The next step after this will be to move OS-specific code, which I expect will
include many of the tool implementations, to similarly separate files.

Some CPU-specific functions are not being moved just yet. In cases where the
only caller is the platform-specific tools, I plan to move them together. An
example is Hexagon, where the only caller of the architecture-specific functions
are the tools themselves. (I'm happy to revise this choice, it just seems like
less churn to me.)

This does mean that some functions which were previously static are now exposed
through the library header Driver.h.

Reviewers: rsmith, javed.absar

Subscribers: aemerson, danalbert, srhines, dschuff, jyknight, nemanjai, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30315

llvm-svn: 296056
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This patch moves helper functions that are CPU-specific out of Driver.cpp and to
separate implementation files. The new files are named for the architecture,
e.g. ARMArch.cpp.

The next step after this will be to move OS-specific code, which I expect will
include many of the tool implementations, to similarly separate files.

Some CPU-specific functions are not being moved just yet. In cases where the
only caller is the platform-specific tools, I plan to move them together. An
example is Hexagon, where the only caller of the architecture-specific functions
are the tools themselves. (I'm happy to revise this choice, it just seems like
less churn to me.)

This does mean that some functions which were previously static are now exposed
through the library header Driver.h.

Reviewers: rsmith, javed.absar

Subscribers: aemerson, danalbert, srhines, dschuff, jyknight, nemanjai, mgorny, cfe-commits

Differential Revision: https://reviews.llvm.org/D30315

llvm-svn: 296056
</pre>
</div>
</content>
</entry>
<entry>
<title>Driver: inline a single caller of a function (NFC)</title>
<updated>2017-02-19T21:50:40+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2017-02-19T21:50:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=1577023414445264527eee1f60021268660a372f'/>
<id>1577023414445264527eee1f60021268660a372f</id>
<content type='text'>
Inline the addCompilerRT call to the single caller.  NFC.

llvm-svn: 295620
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Inline the addCompilerRT call to the single caller.  NFC.

llvm-svn: 295620
</pre>
</div>
</content>
</entry>
<entry>
<title>Always use --eh-frame-hdr on OpenBSD, even for -static</title>
<updated>2017-02-19T20:11:48+00:00</updated>
<author>
<name>Brad Smith</name>
<email>brad@comstyle.com</email>
</author>
<published>2017-02-19T20:11:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=e2abc4c065b9424f76b185682d6d89af1b645a84'/>
<id>e2abc4c065b9424f76b185682d6d89af1b645a84</id>
<content type='text'>
llvm-svn: 295614
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
llvm-svn: 295614
</pre>
</div>
</content>
</entry>
<entry>
<title>Link static PIE programs against rcrt0.o on OpenBSD</title>
<updated>2017-02-19T19:33:26+00:00</updated>
<author>
<name>Brad Smith</name>
<email>brad@comstyle.com</email>
</author>
<published>2017-02-19T19:33:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=6a1b7a4acc1914bd085a6a4d210bee3d97e9d3c1'/>
<id>6a1b7a4acc1914bd085a6a4d210bee3d97e9d3c1</id>
<content type='text'>
Patch by Stefan Kempf.

llvm-svn: 295610
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Patch by Stefan Kempf.

llvm-svn: 295610
</pre>
</div>
</content>
</entry>
<entry>
<title>[CUDA] Don't pass -stack-protector to NVPTX compilations.</title>
<updated>2017-02-19T19:05:32+00:00</updated>
<author>
<name>Justin Lebar</name>
<email>jlebar@google.com</email>
</author>
<published>2017-02-19T19:05:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=63152d10c9fc88c9d9e942b46ef2cd3d254ff452'/>
<id>63152d10c9fc88c9d9e942b46ef2cd3d254ff452</id>
<content type='text'>
We can't support stack-protector on NVPTX because NVPTX doesn't expose a
stack to the compiler!

Fixes PR32009.

llvm-svn: 295609
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We can't support stack-protector on NVPTX because NVPTX doesn't expose a
stack to the compiler!

Fixes PR32009.

llvm-svn: 295609
</pre>
</div>
</content>
</entry>
<entry>
<title>[XRAY][MIPS] Add -fxray-instrument for mips/mipsel/mips64/mips64el</title>
<updated>2017-02-15T10:41:38+00:00</updated>
<author>
<name>Sagar Thakur</name>
<email>sagar.thakur@imgtec.com</email>
</author>
<published>2017-02-15T10:41:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.belthelziquor.com/llvm-project.git/commit/?id=9d0ed930ec9a47a2fc2acb9b633ea186b7af669d'/>
<id>9d0ed930ec9a47a2fc2acb9b633ea186b7af669d</id>
<content type='text'>
Summary: Adds xray instrument option for mips/mipsel/mips64/mips64el.

Reviewed by sdardis, dberris
Differential: D27698

llvm-svn: 295163
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Summary: Adds xray instrument option for mips/mipsel/mips64/mips64el.

Reviewed by sdardis, dberris
Differential: D27698

llvm-svn: 295163
</pre>
</div>
</content>
</entry>
</feed>
