summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* Add Windows Control Flow Guard checks (/guard:cf).Andrew Paverd2019-10-281-2/+5
| | | | | | | | | | | | | | | | | | | 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
* [ARM][AArch64] Implement __cls, __clsl and __clsll intrinsics from ACLEvhscampos2019-10-281-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Writing support for three ACLE functions: unsigned int __cls(uint32_t x) unsigned int __clsl(unsigned long x) unsigned int __clsll(uint64_t x) CLS stands for "Count number of leading sign bits". In AArch64, these two intrinsics can be translated into the 'cls' instruction directly. In AArch32, on the other hand, this functionality is achieved by implementing it in terms of clz (count number of leading zeros). Reviewers: compnerd Reviewed By: compnerd Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69250
* OpenMP: Add convergent to more runtime functionsMatt Arsenault2019-10-271-2/+2
| | | | | Several of these other functions are probably also convergent, but these two seem obviously convergent.
* OpenMP: Add helper function for convergent runtime callsMatt Arsenault2019-10-273-11/+25
| | | | | | Most of the functions emitted here should probably be convergent, but only barriers are currently marked. Introduce this helper before adding convergent to more functions.
* Fix compilation warning. NFC.Michael Liao2019-10-251-0/+1
|
* [hip] Allow the declaration of functions with variadic arguments in HIP.Michael Liao2019-10-251-0/+7
| | | | | | | | | | | | | | | | | 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
* Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""Jordan Rupprecht2019-10-241-8/+0
| | | | | | | | | | | | | | This reverts commit 80371c74ae63d2f260bcc75408be9c6f81e38465. Given the following source: ``` void a() { for (;;) ; } ``` It incorrectly enables vectorization (with vector width 1), as well as generating a warning that vectorization could not be performed.
* [clang]Fixup clang -Werror,,-Wcovered-switch-default build failuresJinsong Ji2019-10-241-3/+0
| | | | | | | | | llvm/clang/lib/CodeGen/CGBuiltin.cpp:6877:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] Similar to https://reviews.llvm.org/rG7b3de1e811972b874d91554642ccb2ef5b32eed6
* [clang,ARM] Initial ACLE intrinsics for MVE.Simon Tatham2019-10-242-6/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit sets up the infrastructure for auto-generating <arm_mve.h> and doing clang-side code generation for the builtins it relies on, and demonstrates that it works by implementing a representative sample of the ACLE intrinsics, more or less matching the ones introduced in LLVM IR by D67158,D68699,D68700. Like NEON, that header file will provide a set of vector types like uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON, the ACLE spec for <arm_mve.h> includes a polymorphism system, so that you can write plain vaddq() and disambiguate by the vector types you pass to it. Unlike the corresponding NEON code, I've arranged to make every user- facing ACLE intrinsic into a clang builtin, and implement all the code generation inside clang. So <arm_mve.h> itself contains nothing but typedefs and function declarations, with the latter all using the new `__attribute__((__clang_builtin))` system to arrange that the user- facing function names correspond to the right internal BuiltinIDs. So the new MveEmitter tablegen system specifies the full sequence of IRBuilder operations that each user-facing ACLE intrinsic should translate into. Where possible, the ACLE intrinsics map to standard IR operations such as vector-typed `add` and `fadd`; where no standard representation exists, I call down to the sample IR intrinsics introduced in an earlier commit. Doing it like this means that you get the polymorphism for free just by using __attribute__((overloadable)): the clang overload resolution decides which function declaration is the relevant one, and _then_ its BuiltinID is looked up, so by the time we're doing code generation, that's all been resolved by the standard system. It also means that you get really nice error messages if the user passes the wrong combination of types: clang will show the declarations from the header file and explain why each one doesn't match. (The obvious alternative approach would be to have wrapper functions in <arm_mve.h> which pass their arguments to the underlying builtins. But that doesn't work in the case where one of the arguments has to be a constant integer: the wrapper function can't pass the constantness through. So you'd have to do that case using a macro instead, and then use C11 `_Generic` to handle the polymorphism. Then you have to add horrible workarounds because `_Generic` requires even the untaken branches to type-check successfully, and //then// if the user gets the types wrong, the error message is totally unreadable!) Reviewers: dmgreen, miyuki, ostannard Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67161
* [HIP] Add option -fgpu-allow-device-initYaxun (Sam) Liu2019-10-221-1/+6
| | | | | | | | | | | | | | 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
* PCH debug info: Avoid appending the source directory to an absolute pathAdrian Prantl2019-10-211-3/+3
| | | | | | | | | | | | | | When building a precompiled header in -fmodule-format=obj (i.e., `-gmodules) in an absolute path, the locig in CGDebugInfo::createCompileUnit would unconditionally append the source directory to the -main-file-name. This patch avoids that behavior for absolute paths. rdar://problem/46045865 Differential Revision: https://reviews.llvm.org/D69213 llvm-svn: 375423
* [AMDGPU] Fix assertion due to initializer listYaxun Liu2019-10-201-10/+6
| | | | | | | | | | | | | Sometimes a global var is replaced by a different llvm value. clang use GetAddrOfGlobalVar to get the original llvm global variable. For most targets, GetAddrOfGlobalVar returns either the llvm global variable or a bitcast of the llvm global variable. However, for AMDGPU target, GetAddrOfGlobalVar returns the addrspace cast or addrspace cast plus bitcast of the llvm global variable. To get the llvm global variable, these casts need to be stripped, otherwise there is assertion. This patch fixes that. Differential Revision: https://reviews.llvm.org/D69129 llvm-svn: 375362
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-194-0/+13
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* DebugInfo: Render the canonical name of a class template specialization, ↵David Blaikie2019-10-181-1/+3
| | | | | | | | even when nested in another class template specialization Differential Revision: https://reviews.llvm.org/D63031 llvm-svn: 375304
* [OPENMP50]Add support for master taskloop simd.Alexey Bataev2019-10-185-0/+25
| | | | | | Added trsing/semantics/codegen for combined construct master taskloop simd. llvm-svn: 375255
* [OPENMP]Improve use of the global tid parameter.Alexey Bataev2019-10-171-9/+14
| | | | | | | | If we can determined, that the global tid parameter can be used in the function, better to use it rather than calling __kmpc_global_thread_num function. llvm-svn: 375134
* [OPENMP]Fix thread id passed to outlined region in sequential parallelAlexey Bataev2019-10-171-5/+3
| | | | | | | | | regions. The real global thread id must be passed to the outlined region instead of the zero thread id. llvm-svn: 375119
* [OpenCL] Preserve addrspace in CGClass (PR43145)Sven van Haastregt2019-10-171-2/+5
| | | | | | | | | | PR43145 revealed two places where Clang was attempting to create a bitcast without considering the address space of class types during C++ class code generation. Differential Revision: https://reviews.llvm.org/D68403 llvm-svn: 375118
* Reland: Dead Virtual Function EliminationOliver Stannard2019-10-174-42/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert Tag CFI-generated data structures with "#pragma clang section" ↵Dmitry Mikulin2019-10-173-30/+5
| | | | | | | | attributes. This reverts r375022 (git commit e2692b3bc0327606748b6d291b9009d2c845ced5) llvm-svn: 375069
* Tag CFI-generated data structures with "#pragma clang section" attributes.Dmitry Mikulin2019-10-163-5/+30
| | | | | | Differential Revision: https://reviews.llvm.org/D68808 llvm-svn: 375022
* [OPENMP]Use different addresses for zeroed thread_id/bound_id.Alexey Bataev2019-10-162-19/+26
| | | | | | | | When the parallel region is called directly in the sequential region, the zeroed tid/bound id are used. But they must point to the different memory locations as the parameters are marked as noalias. llvm-svn: 375017
* [DWARF5] Added support for DW_AT_noreturn attribute to be emitted forAdrian Prantl2019-10-161-0/+2
| | | | | | | | | | C++ class member functions. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D68697 llvm-svn: 375012
* CGDebugInfo - silence static analyzer dyn_cast<> null dereference warnings. ↵Simon Pilgrim2019-10-161-4/+5
| | | | | | | | NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use cast<> directly and if not assert will fire for us. llvm-svn: 374989
* CGExprConstant - silence static analyzer getAs<> null dereference warning. NFCI.Simon Pilgrim2019-10-161-2/+2
| | | | | | The static analyzer is warning about a potential null dereference, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374988
* CGBuiltin - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim2019-10-161-5/+4
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 374987
* [Clang][OpenMP Offload] Move offload registration code to the wrapperSergey Dmitriev2019-10-153-191/+7
| | | | | | | | | | 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
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-152-0/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* CFI: wrong type passed to llvm.type.test with multiple inheritance ↵Dmitry Mikulin2019-10-151-1/+1
| | | | | | | | devirtualization. Differential Revision: https://reviews.llvm.org/D67985 llvm-svn: 374909
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+4
| | | | | | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is refe$ D41217 on Phabricator. (recommit after fixing failing Parser test on windows) llvm-svn: 374903
* Revert 374882 "[Concepts] Concept Specialization Expressions"Nico Weber2019-10-151-4/+0
| | | | | | | | | | This reverts commit ec87b003823d63f3342cf648f55a134c1522e612. The test fails on Windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11533/steps/stage%201%20check/logs/stdio Also revert follow-up r374893. llvm-svn: 374899
* [Alignment] Migrate Attribute::getWith(Stack)AlignmentGuillaume Chatelet2019-10-151-2/+2
| | | | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, jdoerfert Reviewed By: courbet Subscribers: arsenm, jvesely, nhaehnle, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68792 llvm-svn: 374884
* [Concepts] Concept Specialization ExpressionsSaar Raz2019-10-151-0/+4
| | | | | | Part of C++20 Concepts implementation effort. Added Concept Specialization Expressions that are created when a concept is referenced with arguments, and tests thereof. llvm-svn: 374882
* [WebAssembly] Trapping fptoint builtins and intrinsicsThomas Lively2019-10-151-0/+20
| | | | | | | | | | | | | | | | | | | | | Summary: The WebAssembly backend lowers fptoint instructions to a code sequence that checks for overflow to avoid traps because fptoint is supposed to be speculatable. These new builtins and intrinsics give users a way to depend on the trapping semantics of the underlying instructions and avoid the extra code generated normally. Patch by coffee and tlively. Reviewers: aheejin Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68902 llvm-svn: 374856
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-144-126/+42
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* [OPENMP50]Add support for 'parallel master taskloop' construct.Alexey Bataev2019-10-145-1/+33
| | | | | | | | | Added parsing/sema/codegen support for 'parallel master taskloop' constructs. Some of the clauses, like 'grainsize', 'num_tasks', 'final' and 'priority' are not supported in full, only constant expressions can be used currently in these clauses. llvm-svn: 374791
* [IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperatorCameron McInally2019-10-141-6/+8
| | | | | | | | Reapply r374240 with fix for Ocaml test, namely Bindings/OCaml/core.ml. Differential Revision: https://reviews.llvm.org/D61675 llvm-svn: 374782
* Improve __builtin_constant_p loweringJoerg Sonnenberger2019-10-131-4/+0
| | | | | | | | | | | | | | | | __builtin_constant_p used to be short-cut evaluated to false when building with -O0. This is undesirable as it means that constant folding in the front-end can give different results than folding in the back-end. It can also create conditional branches on constant conditions that don't get folded away. With the pending improvements to the llvm.is.constant handling on the LLVM side, the short-cut is no longer useful. Adjust various codegen tests to not depend on the short-cut or the backend optimisations. Differential Revision: https://reviews.llvm.org/D67638 llvm-svn: 374742
* remove an useless allocation found by scan-build - the new Dead nested ↵Sylvestre Ledru2019-10-121-2/+2
| | | | | | assignment check llvm-svn: 374659
* Reland r374450 with Richard Smith's comments and test fixed.Erich Keane2019-10-116-32/+14
| | | | | | | | | | The behavior from the original patch has changed, since we're no longer allowing LLVM to just ignore the alignment. Instead, we're just assuming the maximum possible alignment. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374562
* Dead Virtual Function EliminationOliver Stannard2019-10-114-42/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Insert module constructors in a module passVitaly Buka2019-10-111-2/+11
| | | | | | | | | | | | | | | | | | | | | Summary: If we insert them from function pass some analysis may be missing or invalid. Fixes PR42877. Reviewers: eugenis, leonardchan Reviewed By: leonardchan Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68832 > llvm-svn: 374481 Signed-off-by: Vitaly Buka <vitalybuka@google.com> llvm-svn: 374527
* Revert 374481 "[tsan,msan] Insert module constructors in a module pass"Nico Weber2019-10-111-11/+2
| | | | | | | CodeGen/sanitizer-module-constructor.c fails on mac and windows, see e.g. http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11424 llvm-svn: 374503
* [tsan,msan] Insert module constructors in a module passVitaly Buka2019-10-101-2/+11
| | | | | | | | | | | | | | | | | | Summary: If we insert them from function pass some analysis may be missing or invalid. Fixes PR42877. Reviewers: eugenis, leonardchan Reviewed By: leonardchan Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68832 llvm-svn: 374481
* Revert 374450 "Fix __builtin_assume_aligned with too large values."Nico Weber2019-10-106-10/+31
| | | | | | | | | | | | | The test fails on Windows, with error: 'warning' diagnostics expected but not seen: File builtin-assume-aligned.c Line 62: requested alignment must be 268435456 bytes or smaller; assumption ignored error: 'warning' diagnostics seen but not expected: File builtin-assume-aligned.c Line 62: requested alignment must be 8192 bytes or smaller; assumption ignored llvm-svn: 374456
* Fix __builtin_assume_aligned with too large values.Erich Keane2019-10-106-31/+10
| | | | | | | | | | | | | | Code to handle __builtin_assume_aligned was allowing larger values, but would convert this to unsigned along the way. This patch removes the EmitAssumeAligned overloads that take unsigned to do away with this problem. Additionally, it adds a warning that values greater than 1 <<29 are ignored by LLVM. Differential Revision: https://reviews.llvm.org/D68824 llvm-svn: 374450
* [OPENMP50]Support for 'master taskloop' directive.Alexey Bataev2019-10-105-0/+23
| | | | | | Added full support for master taskloop directive. llvm-svn: 374437
* Re-land "Use -fdebug-compilation-dir to form absolute paths in coverage ↵Reid Kleckner2019-10-102-9/+24
| | | | | | | | | | | | mappings" This reverts r374324 (git commit 62808631acceaa8b78f8ab9b407eb6b943ff5f77) I changed the test to not rely on finding the sequence "clang, test, CoverageMapping" in the CWD used to run the test. Instead it makes its own internal directory hierarchy of foo/bar/baz and looks for that. llvm-svn: 374403
* [OPENMP50]Support for declare variant directive for NVPTX target.Alexey Bataev2019-10-106-6/+92
| | | | | | | NVPTX does not support global aliases. Instead, we have to copy the full body of the variant function for the original function. llvm-svn: 374387
* Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"Dmitri Gribenko2019-10-101-8/+6
| | | | | | | This reverts commit r374240. It broke OCaml tests: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014 llvm-svn: 374354
OpenPOWER on IntegriCloud