summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver/ToolChains/AMDGPU.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Misc typos fixes in ./lib folderRaphael Isemann2018-12-101-1/+1
| | | | | | | | | | | | | | Summary: Found via `codespell -q 3 -I ../clang-whitelist.txt -L uint,importd,crasher,gonna,cant,ue,ons,orign,ned` Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, jholewinski, jvesely, nhaehnle, whisperity, jfb, cfe-commits Differential Revision: https://reviews.llvm.org/D55475 llvm-svn: 348755
* AMDGPU: Default to hidden visibilityMatt Arsenault2018-08-301-0/+13
| | | | | | | | | | | | Object linking isn't supported, so it's not useful to emit default visibility. Default visibility requires relocations we don't yet support for functions compiled in another translation unit. WebAssembly already does this, although they insert these arguments in a different place for some reason. llvm-svn: 341033
* AMDGPU: Remove amdgpu-debugger-reserve-regs featureKonstantin Zhuravlyov2018-06-211-1/+0
| | | | llvm-svn: 335287
* AMDGPU/NFC: Move getAMDGPUTargetFeatures to AMDGPU toolchainKonstantin Zhuravlyov2017-11-101-0/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D39877 llvm-svn: 317909
* [AMDGPU] Implement infrastructure to set options in AMDGPUToolChainAndrey Kasaurov2017-09-051-2/+39
| | | | | | | | | | | | In current OpenCL implementation some options are set in OpenCL RT/Driver, which causes discrepancy between online and offline paths. Implement infrastructure to move options from OpenCL RT/Driver to AMDGPUToolChain using overloaded TranslateArgs() method. Create map for default options values, as Options.td doesn't support default values (in contrast with OPTIONS.def). Add two driver options: -On and -mNN (like -O3, -m64). Some minor formatting changes to follow the clang-format style. Differential Revision: https://reviews.llvm.org/D37386 llvm-svn: 312524
* Test commitAndrey Kasaurov2017-07-211-1/+1
| | | | llvm-svn: 308744
* Test commitNikolay Haustov2017-07-211-1/+1
| | | | llvm-svn: 308741
* [Driver] Consolidate tools and toolchains by target platform. (NFC)David L. Jones2017-03-081-0/+45
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
OpenPOWER on IntegriCloud