summaryrefslogtreecommitdiffstats
path: root/clang/lib/Driver
Commit message (Collapse)AuthorAgeFilesLines
...
* Build fix after 4b6597fNico Weber2019-10-311-1/+1
|
* Make flang driver stuff work on macOSNico Weber2019-10-311-1/+1
| | | | | | | | | | | 6bf55804 added special-case code for TY_PP_Fortran to ToolChain::LookupTypeForExtension(), but Darwin::LookupTypeForExtension() overrode that method without calling the superclass implementation. Make it call the superclass implementation to fix things. Differential Revision: https://reviews.llvm.org/D69636
* [cfi] Add flag to always generate .debug_frameDavid Candler2019-10-311-0/+4
| | | | | | | | | This adds a flag to LLVM and clang to always generate a .debug_frame section, even if other debug information is not being generated. In situations where .eh_frame would normally be emitted, both .debug_frame and .eh_frame will be used. Differential Revision: https://reviews.llvm.org/D67216
* Revert "[CodeView] Add option to disable inline line tables."Amy Huang2019-10-301-6/+0
| | | | | | because it breaks compiler-rt tests. This reverts commit 6d03890384517919a3ba7fe4c35535425f278f89.
* [CodeView] Add option to disable inline line tables.Amy Huang2019-10-301-0/+6
| | | | | | | | | | | | | | | | | Summary: This adds a clang option to disable inline line tables. When it is used, the inliner uses the call site as the location of the inlined function instead of marking it as an inline location with the function location. See https://bugs.llvm.org/show_bug.cgi?id=42344 Reviewers: rnk Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D67723
* [clang][driver] Add basic --driver-mode=flang support for fortranPeter Waller2019-10-306-1/+168
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a new Flang mode. When in Flang mode, the driver will invoke flang for fortran inputs instead of falling back to the GCC toolchain as it would otherwise do. The behaviour of other driver modes are left unmodified to preserve backwards compatibility. It is intended that a soon to be implemented binary in the flang project will import libclangDriver and run the clang driver in the new flang mode. Please note that since the binary invoked by the driver is under development, there will no doubt be further tweaks necessary in future commits. * Initial support is added for basic driver phases * -E, -fsyntax-only, -emit-llvm -S, -emit-llvm, -S, (none specified) * -### tests are added for all of the above * This is more than is supported by f18 so far, which will emit errors for those options which are unimplemented. * A test is added that ensures that clang gives a reasonable error message if flang is not available in the path (without -###). * Test that the driver accepts multiple inputs in --driver-mode=flang. * Test that a combination of C and Fortran inputs run both clang and flang in --driver-mode=flang. * clang/test/Driver/fortran.f95 is fixed to use the correct fortran comment character. Differential revision: https://reviews.llvm.org/D63607
* [Driver] Enable ShadowCallStack, not SafeStack, by default on AArch64 FuchsiaLeonard Chan2019-10-281-1/+6
| | | | | | | | | | | Submitted for mcgrathr. On AArch64, Fuchsia fully supports both SafeStack and ShadowCallStack ABIs. The latter is now preferred and will be the default. It's possible to enable both simultaneously, but ShadowCallStack is believed to have most of the practical benefit of SafeStack with less cost. Differential Revision: https://reviews.llvm.org/D66712
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-282-19/+34
| | | | | | | | | | | | | | | | | | | Summary: A new function pass (Transforms/CFGuard/CFGuard.cpp) inserts CFGuard checks on indirect function calls, using either the check mechanism (X86, ARM, AArch64) or or the dispatch mechanism (X86-64). The check mechanism requires a new calling convention for the supported targets. The dispatch mechanism adds the target as an operand bundle, which is processed by SelectionDAG. Another pass (CodeGen/CFGuardLongjmp.cpp) identifies and emits valid longjmp targets, as required by /guard:cf. This feature is enabled using the `cfguard` CC1 option. Reviewers: thakis, rnk, theraven, pcc Subscribers: ychen, hans, metalcanine, dmajor, tomrittervg, alex, mehdi_amini, mgorny, javed.absar, kristof.beyls, hiraditya, steven_wu, dexonsmith, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65761
* [hip] Allow the declaration of functions with variadic arguments in HIP.Michael Liao2019-10-252-0/+5
| | | | | | | | | | | | | | | | | Summary: - As variadic parameters have the lowest rank in overload resolution, without real usage of `va_arg`, they are commonly used as the catch-all fallbacks in SFINAE. As the front-end still reports errors on calls to `va_arg`, the declaration of functions with variadic arguments should be allowed in general. Reviewers: jlebar, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69389
* [clang][ThinLTO] Promote cc1 -fthin_link_bitcode to driver ↵Yuanfang Chen2019-10-241-0/+3
| | | | | | | | | | | | | | | | | -fthinlto_link_bitcode Summary: A necessary step to let build system caching work for its output. Reviewers: tejohnson, steven_wu Reviewed by: tejohnson Subscribers: mehdi_amini, inglorion, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69406
* Follow on to Namespace fixup for D68340David Tenty2019-10-241-1/+0
| | | | remove using directive that can make lookup ambiguous.
* Namespace fixup for D68340 build on MSVCDavid Tenty2019-10-241-0/+2
| | | | | we seem to run into issues with nested namespace lookups in recently landed D68340 so just make them explicit.
* Add AIX toolchain and basic linker functionalitystevewan2019-10-244-0/+169
| | | | | | | | | | | | | | | | Summary: This patch adds AIX toolchain infrastructure into driver, and enables AIX system linker invocation with some basic functionality support Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L Reviewed By: jasonliu Subscribers: Xiangling_L, jasonliu, ormris, wuzish, nemanjai, mgorny, kbarton, jfb, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68340
* Don't add -fsplit-lto-unit for thin LTO builds with PS4 and Darwin toolchainsevgeny2019-10-243-1/+10
| | | | | These toolchains use legacy thin LTO API, which is not capable of unit splitting Differential revision: https://reviews.llvm.org/D69173
* [RISCV] Add support for -ffixed-xX flagsSimon Cook2019-10-221-0/+64
| | | | | | | | | | | This adds support for reserving GPRs such that the compiler will not choose a register for register allocation. The implementation follows the same design as for AArch64; each reserved register becomes a target feature and used for getting the reserved registers for a given MachineFunction. The backend checks that it does not need to write to any reserved register; if it does a relevant error is generated. Differential Revision: https://reviews.llvm.org/D67185
* [HIP] Add option -fgpu-allow-device-initYaxun (Sam) Liu2019-10-221-0/+4
| | | | | | | | | | | | | | Add this option to allow device side class type global variables with non-trivial ctor/dtor. device side init/fini functions will be emitted, which will be executed by HIP runtime when the fat binary is loaded/unloaded. This feature is to facilitate implementation of device side sanitizer which requires global vars with non-trival ctors. By default this option is disabled. Differential Revision: https://reviews.llvm.org/D69268
* Fix -fuse-init-array decision logic on NetBSDJoerg Sonnenberger2019-10-211-1/+14
| | | | | | | For NetBSD 9 and later, it is the default. On older versions, only ARM and AArch64 use it by default. llvm-svn: 375468
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-194-0/+4
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* [clang][driver] Print compilation phases with indentation.Michael Liao2019-10-191-5/+24
| | | | | | | | | | | | Reviewers: tra, sfantao, echristo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69124 llvm-svn: 375310
* [profile] Do not cache __llvm_profile_get_filename resultVedant Kumar2019-10-181-1/+0
| | | | | | | | | | | | | | | | | When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 llvm-svn: 375301
* [ThinLTOCodeGenerator] Add support for index-based WPDEugene Leviant2019-10-181-7/+1
| | | | | | | | | This is clang part of the patch. It adds -flto-unit flag for thin LTO builds on Mac and PS4 Differential revision: https://reviews.llvm.org/D68950 llvm-svn: 375224
* [WebAssembly] -pthread implies -target-feature +sign-extThomas Lively2019-10-181-1/+8
| | | | | | | | | | | | | | | | | Summary: The sign extension proposal was motivated by a desire to not have separate sign-extending atomic operations, so it is meant to be enabled when threads are used. Reviewers: aheejin, dschuff Subscribers: sbc100, jgravelle-google, sunfish, jfb, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69075 llvm-svn: 375199
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-171-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove dead virtual functions from vtables with replaceNonMetadataUsesWith, so that CGProfile metadata gets cleaned up correctly. Original commit message: Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 375094
* [Driver,ARM] Make -mfloat-abi=soft turn off MVE.Simon Tatham2019-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since `-mfloat-abi=soft` is taken to mean turning off all uses of the FP registers, it should turn off the MVE vector instructions as well as NEON and scalar FP. But it wasn't doing so. So the options `-march=armv8.1-m.main+mve.fp+fp.dp -mfloat-abi=soft` would cause the underlying LLVM to //not// support MVE (because it knows the real target feature relationships and turned off MVE when the `fpregs` feature was removed), but the clang layer still thought it //was// supported, and would misleadingly define the feature macro `__ARM_FEATURE_MVE`. The ARM driver code already has a long list of feature names to turn off when `-mfloat-abi=soft` is selected. The fix is to add the missing entries `mve` and `mve.fp` to that list. Reviewers: dmgreen Subscribers: kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69025 llvm-svn: 375001
* [Clang][OpenMP Offload] Move offload registration code to the wrapperSergey Dmitriev2019-10-151-27/+3
| | | | | | | | | | The final list of OpenMP offload targets becomes known only at the link time and since offload registration code depends on the targets list it makes sense to delay offload registration code generation to the link time instead of adding it to the host part of every fat object. This patch moves offload registration code generation from clang to the offload wrapper tool. This is the last part of the OpenMP linker script elimination patch https://reviews.llvm.org/D64943 Differential Revision: https://reviews.llvm.org/D68746 llvm-svn: 374937
* Reland [Driver] Fix -working-directory issuesJan Korous2019-10-152-33/+24
| | | | | | | | Don't change the default VFS in Driver, update tests & reland. This reverts commit 999f8a7416f8edc54ef92e715fd23c532bcc74d4. llvm-svn: 374926
* Reapply: [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-151-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 > llvm-svn: 374841 llvm-svn: 374895
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-141-24/+3
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* Temporarily Revert [Modules][PCH] Hash input files contentEric Christopher2019-10-141-8/+0
| | | | | | | | as it's breaking a few bots. This reverts r374841 (git commit 2a1386c81de504b5bda44fbecf3f7b4cdfd748fc) llvm-svn: 374842
* [Modules][PCH] Hash input files contentBruno Cardoso Lopes2019-10-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When files often get touched during builds, the mtime based validation leads to different problems in implicit modules builds, even when the content doesn't actually change: - Modules only: module invalidation due to out of date files. Usually causing rebuild traffic. - Modules + PCH: build failures because clang cannot rebuild a module if it comes from building a PCH. - PCH: build failures because clang cannot rebuild a PCH in case one of the input headers has different mtime. This patch proposes hashing the content of input files (headers and module maps), which is performed during serialization time. When looking at input files for validation, clang only computes the hash in case there's a mtime mismatch. I've tested a couple of different hash algorithms availble in LLVM in face of building modules+pch for `#import <Cocoa/Cocoa.h>`: - `hash_code`: performace diff within the noise, total module cache increased by 0.07%. - `SHA1`: 5% slowdown. Haven't done real size measurements, but it'd be BLOCK_ID+20 bytes per input file, instead of BLOCK_ID+8 bytes from `hash_code`. - `MD5`: 3% slowdown. Like above, but BLOCK_ID+16 bytes per input file. Given the numbers above, the patch uses `hash_code`. The patch also improves invalidation error msgs to point out which type of problem the user is facing: "mtime", "size" or "content". rdar://problem/29320105 Reviewers: dexonsmith, arphaman, rsmith, aprantl Subscribers: jkorous, cfe-commits, ributzka Tags: #clang Differential Revision: https://reviews.llvm.org/D67249 llvm-svn: 374841
* Add support to -Wa,-W in clangJian Cai2019-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: Currently clang does not support -Wa,-W, which suppresses warning messages in GNU assembler. Add this option for gcc compatibility. https://bugs.llvm.org/show_bug.cgi?id=43651. Reland with differential information. Reviewers: bcain Reviewed By: bcain Subscribers: george.burgess.iv, gbiv, llozano, manojgupta, nickdesaulniers, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68884 llvm-svn: 374834
* Revert "Add support to -Wa,-W in clang"Jian Cai2019-10-141-1/+1
| | | | | | This reverts commit e72eeca43b9577be2aae55f7603febbf223a6ab3. llvm-svn: 374833
* Add support to -Wa,-W in clangJian Cai2019-10-141-1/+1
| | | | | | | | Currently clang does not support -Wa,-W, which suppresses warning messages in GNU assembler. Add this option for gcc compatibility. https://bugs.llvm.org/show_bug.cgi?id=43651 llvm-svn: 374822
* [clang-scan-deps] Support for clang --analyze in clang-scan-depsJan Korous2019-10-141-0/+4
| | | | | | | | | | | | | | | The goal is to have 100% fidelity in clang-scan-deps behavior when --analyze is present in compilation command. At the same time I don't want to break clang-tidy which expects __static_analyzer__ macro defined as built-in. I introduce new cc1 options (-setup-static-analyzer) that controls the macro definition and is conditionally set in driver. Differential Revision: https://reviews.llvm.org/D68093 llvm-svn: 374815
* [ARM] Preserve fpu behaviour for '-crypto'Diogo N. Sampaio2019-10-141-18/+27
| | | | | | | | | | | | | | | | | | | | | Summary: This patch restores the behaviour that -fpu overwrites the architecture obtained from -march or -mcpu flags, not enforcing to disable 'crypto' if march=armv7 and mfpu=neon-fp-armv8. However, it does warn that 'crypto' is ignored when passing mfpu=crypto-neon-fp-armv8. Reviewers: peter.smith, labrinea Reviewed By: peter.smith Subscribers: nickdesaulniers, kristof.beyls, dmgreen, cfe-commits, krisb Tags: #clang Differential Revision: https://reviews.llvm.org/D67608 llvm-svn: 374785
* [RISCV] enable LTO support, pass some options to linker.Sam Elliott2019-10-145-89/+136
| | | | | | | | | | | | | | | | | | | | | | | | Summary: 1. enable LTO need to pass target feature and abi to LTO code generation RISCV backend need the target feature to decide which extension used in code generation. 2. move getTargetFeatures to CommonArgs.h and add ForLTOPlugin flag 3. add general tools::getTargetABI in CommonArgs.h because different target uses different way to get the target ABI. Patch by Kuan Hsu Chen (khchen) Reviewers: lenary, lewis-revill, asb, MaskRay Reviewed By: lenary Subscribers: hiraditya, dschuff, aheejin, fedor.sergeev, mehdi_amini, inglorion, asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, steven_wu, rogfer01, MartinMosbeck, brucehoult, the_o, dexonsmith, rkruppe, PkmX, jocewei, psnobl, benna, Jim, lenary, s.egerton, pzheng, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67409 llvm-svn: 374774
* [clang][IFS] Fixing spelling errors in interface-stubs OPT flag (NFC).Puyan Lotfi2019-10-123-5/+5
| | | | | | This is just a long standing spelling error that was found recently. llvm-svn: 374638
* Dead Virtual Function EliminationOliver Stannard2019-10-111-3/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 374539
* Add -fgnuc-version= to control __GNUC__ and other GCC macrosReid Kleckner2019-10-101-5/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I noticed that compiling on Windows with -fno-ms-compatibility had the side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and a number of other macros for GCC compatibility. This is undesirable and causes Chromium to do things like mix __attribute__ and __declspec, which doesn't work. We should have a positive language option to enable GCC compatibility features so that we can experiment with -fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be that option. My issue aside, users have, for a long time, reported that __GNUC__ doesn't match their expectations in one way or another. We have encouraged users to migrate code away from this macro, but new code continues to be written assuming a GCC-only environment. There's really nothing we can do to stop that. By adding this flag, we can allow them to choose their own adventure with __GNUC__. This overlaps a bit with the "GNUMode" language option from -std=gnu*. The gnu language mode tends to enable non-conforming behaviors that we'd rather not enable by default, but the we want to set things like __GXX_RTTI__ by default, so I've kept these separate. Helps address PR42817 Reviewed By: hans, nickdesaulniers, MaskRay Differential Revision: https://reviews.llvm.org/D68055 llvm-svn: 374449
* [MSVC] Automatically add atlmfc folder to include and libpath.Zachary Turner2019-10-102-3/+16
| | | | | | Differential Revision: https://reviews.llvm.org/D68736 llvm-svn: 374443
* [Clang][OpenMP Offload] Add new tool for wrapping offload device binariesSergey Dmitriev2019-10-099-142/+128
| | | | | | | | | | This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver. This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943). Differential Revision: https://reviews.llvm.org/D68166 llvm-svn: 374219
* [HIP] Fix -save-tempsYaxun Liu2019-10-094-32/+57
| | | | | | | | | | Currently clang does not save some of the intermediate file generated during device compilation for HIP when -save-temps is specified. This patch fixes that. Differential Revision: https://reviews.llvm.org/D68665 llvm-svn: 374198
* [mips] Set default float ABI to "soft" on FreeBSDSimon Atanasyan2019-10-094-9/+17
| | | | | | | | Initial patch by Kyle Evans. Fix PR43596 llvm-svn: 374154
* [driver][hip] Skip bundler if host action is nothing.Michael Liao2019-10-081-1/+2
| | | | | | | | | | | | Reviewers: sfantao, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68652 llvm-svn: 374097
* [clang][ifs] Clang Interface Stubs ToolChain plumbing.Puyan Lotfi2019-10-089-29/+141
| | | | | | | | | | | | | | | | | | | | | | | Second Landing Attempt: This patch enables end to end support for generating ELF interface stubs directly from clang. Now the following: clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp will product an ELF binary with visible symbols populated. Visibility attributes and -fvisibility can be used to control what gets populated. * Adding ToolChain support for clang Driver IFS Merge Phase * Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain * Adds support for the clang Driver to involve llvm-ifs on ifs files. * Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file instead of the final object format (normally ELF) Differential Revision: https://reviews.llvm.org/D63978 llvm-svn: 374061
* [Driver] NFC: Remove duplicate call to getLibGccTypeCullen Rhodes2019-10-041-1/+0
| | | | | | | | Reviewed By: saugustine Differential Revision: https://reviews.llvm.org/D68380 llvm-svn: 373712
* [HIP] Use option -nogpulib to disable linking device libYaxun Liu2019-10-032-2/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D68300 llvm-svn: 373649
* [HIP] Enable specifying different default gpu arch for HIP/CUDA.Michael Liao2019-10-031-3/+11
| | | | | | | | | | | | Reviewers: tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68394 llvm-svn: 373634
* [HIP] Support -emit-llvm for device compilationYaxun Liu2019-10-031-2/+8
| | | | | | | | | | | Sometimes it is useful to compile HIP device code to LLVM BC. It is not convenient to use clang -cc1 since there are lots of options needed. This patch allows clang driver to compile HIP device code to LLVM BC with -emit-llvm -c. Differential Revision: https://reviews.llvm.org/D68284 llvm-svn: 373561
* Revert 373538 and follow-ups 373549 and 373552.Nico Weber2019-10-039-141/+29
| | | | | | They break tests on (at least) macOS. llvm-svn: 373556
OpenPOWER on IntegriCloud