summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
...
* Add getBeginLoc API to replace getStartLocStephen Kelly2018-08-091-1/+2
| | | | | | | | | | Reviewers: teemperor! Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50347 llvm-svn: 339373
* Correctly initialise global blocks on Windows.David Chisnall2018-08-091-2/+26
| | | | | | | | | | | | | | | | | | Summary: Windows does not allow globals to be initialised to point to globals in another DLL. Exported globals may be referenced only from code. Work around this by creating an initialiser that runs in early library initialisation and sets the isa pointer. Reviewers: rjmccall Reviewed By: rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50436 llvm-svn: 339317
* [Builtins] Implement __builtin_clrsb to be compatible with gccCraig Topper2018-08-081-0/+20
| | | | | | | | | | gcc defines an intrinsic called __builtin_clrsb which counts the number of extra sign bits on a number. This is equivalent to counting the number of leading zeros on a positive number or the number of leading ones on a negative number and subtracting one from the result. Since we can't count leading ones we need to invert negative numbers to count zeros. This patch will cause the builtin to be expanded inline while gcc uses a call to a function like clrsbdi2 that is implemented in libgcc. But this is similar to what we already do for popcnt. And I don't think compiler-rt supports clrsbdi2. Differential Revision: https://reviews.llvm.org/D50168 llvm-svn: 339282
* [CodeGen][Timers] Enable llvm::TimePassesIsEnabled when -ftime-report is ↵Craig Topper2018-08-081-0/+1
| | | | | | | | | | specified r330571 added a new FrontendTimesIsEnabled variable and replaced many usages of llvm::TimePassesIsEnabled. Including the place that set llvm::TimePassesIsEnabled for -ftime-report. The effect of this is that -ftime-report now only contains the timers specifically referenced in CodeGenAction.cpp and none of the timers in the backend. This commit adds back the assignment, but otherwise leaves everything else unchanged. llvm-svn: 339281
* [DebugInfo][OpenCL] Address post-commit review for r338299Scott Linder2018-08-082-55/+97
| | | | | | | | NFC refactor of code to generate debug info for OpenCL 2.X blocks. Differential Revision: https://reviews.llvm.org/D50099 llvm-svn: 339265
* [CGObjCGNU] Rename GetSelector helper method to fix -Woverloaded-virtual ↵Simon Pilgrim2018-08-081-8/+8
| | | | | | | | | | warning (PR38210) As suggested by @theraven on PR38210, this patch fixes the gcc -Woverloaded-virtual warnings by renaming the extra CGObjCGNU::GetSelector method to CGObjCGNU::GetTypedSelector Differential Revision: https://reviews.llvm.org/D50448 llvm-svn: 339264
* [CodeGen] IncompleteArray Support Balaji V. Iyer2018-08-081-0/+10
| | | | | | | | | Added code to support ArrayType that is not ConstantArray. https://reviews.llvm.org/D49952 rdar://42476155 llvm-svn: 339207
* [NFC] CGDecl factor out constant emissionJF Bastien2018-08-071-47/+56
| | | | | | The code is cleaner this way, and with some changes I'm playing with it makes sense to split it out so we can reuse it. llvm-svn: 339191
* [OPENMP] Mark variables captured in declare target region as implicitlyAlexey Bataev2018-08-073-1/+28
| | | | | | | | | declare target. According to OpenMP 5.0, variables captured in lambdas in declare target regions must be considered as implicitly declare target. llvm-svn: 339152
* [OpenCL] Restore r338899 (reverted in r338904), fixing stack-use-after-returnScott Linder2018-08-071-21/+35
| | | | | | | | | Always emit alloca in entry block for enqueue_kernel builtin. Ensures the statically sized alloca is not converted to DYNAMIC_STACKALLOC later because it is not in the entry block. llvm-svn: 339150
* [objc-gnustep] Don't emit .guess ivar offset vars.David Chisnall2018-08-071-34/+4
| | | | | | | | | | | These were intended to allow non-fragile and fragile ABI code to be mixed, as long as the fragile classes were higher up the hierarchy than the non-fragile ones. Unfortunately: - No one actually wants to do this. - Recent versions of Linux's run-time linker break it. llvm-svn: 339128
* Revert "[DebugInfo] Generate debug information for labels. (Fix PR37395)"Hsiangkai Wang2018-08-063-39/+0
| | | | | | | | | | | Build failed in http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/27258 In lib/CodeGen/LiveDebugVariables.cpp:589, it uses std::prev(MBBI) to get DebugValue's SlotIndex. however, the previous instruction may be also a debug instruction. llvm-svn: 338992
* [DebugInfo] Generate debug information for labels. (Fix PR37395)Hsiangkai Wang2018-08-063-0/+39
| | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. Differential Revision: https://reviews.llvm.org/D45045 llvm-svn: 338989
* [DebugInfo] Use DbgVariableIntrinsic as the base class of variables.Hsiangkai Wang2018-08-061-1/+1
| | | | | | | | | | | | | After refactoring DbgInfoIntrinsic class hierarchy, we use DbgVariableIntrinsic as the base class of variable debug info. In resolveTopLevelMetadata() in CGVTables.cpp, we only care about dbg.value, so we try to cast the instructions to DbgVariableIntrinsic before resolving variables. Differential Revision: https://reviews.llvm.org/D50226 llvm-svn: 338985
* Avoid creating conditional cleanup blocks that contain only ↵Richard Smith2018-08-041-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | @llvm.lifetime.end calls When a non-extended temporary object is created in a conditional branch, the lifetime of that temporary ends outside the conditional (at the end of the full-expression). If we're inserting lifetime markers, this means we could end up generating if (some_cond) { lifetime.start(&tmp); Tmp::Tmp(&tmp); } // ... if (some_cond) { lifetime.end(&tmp); } ... for a full-expression containing a subexpression of the form `some_cond ? Tmp().x : 0`. This patch moves the lifetime start for such a temporary out of the conditional branch so that we don't need to generate an additional basic block to hold the lifetime end marker. This is disabled if we want precise lifetime markers (for asan's stack-use-after-scope checks) or of the temporary has a non-trivial destructor (in which case we'd generate an extra basic block anyway to hold the destructor call). Differential Revision: https://reviews.llvm.org/D50286 llvm-svn: 338945
* [OpenMP] Encode offload target triples into comdat key for offload ↵Sergey Dmitriev2018-08-031-1/+13
| | | | | | | | | | | | initialization code Encoding offload target triples onto comdat group key for offload initialization code guarantees that it will be executed once per each unique combination of offload targets. Differential Revision: https://reviews.llvm.org/D50218 llvm-svn: 338916
* [NFC] Initialize a variable to prevent future invalid deref.Erich Keane2018-08-031-1/+1
| | | | | | | | | Found by KlockWorks, this variable is properly protected, however the conditions in the test that initializes it and the one that uses it could diverge, it seems to me that this is a 'free' init that will prevent issues if one of the conditions is ever modified without the other. llvm-svn: 338909
* Revert "[OpenCL] Always emit alloca in entry block for enqueue_kernel builtin"Vlad Tsyrklevich2018-08-031-33/+20
| | | | | | This reverts commit r338899, it was causing ASan test failures on sanitizer-x86_64-linux-fast. llvm-svn: 338904
* [OpenCL] Always emit alloca in entry block for enqueue_kernel builtinScott Linder2018-08-031-20/+33
| | | | | | | | | Ensures the statically sized alloca is not converted to DYNAMIC_STACKALLOC later because it is not in the entry block. Differential Revision: https://reviews.llvm.org/D50104 llvm-svn: 338899
* [CodeGen] Emit parallel_loop_access for each loop in the loop stack.Michael Kruse2018-08-031-2/+13
| | | | | | | | | | | | | | | | | Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
* [WebAssembly] Support for atomic.wait / atomic.wake builtinsHeejin Ahn2018-08-021-0/+20
| | | | | | | | | | | | | | Summary: Add support for atomic.wait / atomic.wake builtins based on the Wasm thread proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D49396 llvm-svn: 338771
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-021-44/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* [UnrollAndJam] Add unroll_and_jam pragma handlingDavid Green2018-08-012-5/+63
| | | | | | | | | | | | | | This adds support for the unroll_and_jam pragma, to go with the recently added unroll and jam pass. The name of the pragma is the same as is used in the Intel compiler, and most of the code works the same as for unroll. #pragma clang loop unroll_and_jam has been separated into a different patch. This part adds #pragma unroll_and_jam with an optional count, and #pragma no_unroll_and_jam to disable the transform. Differential Revision: https://reviews.llvm.org/D47267 llvm-svn: 338566
* [OPENMP] Change linkage of offloading symbols to support droppingAlexey Bataev2018-07-311-2/+4
| | | | | | | | offload targets. Changed the linkage of omp_offloading.img_start.<triple> and omp_offloading.img_end.<triple> symbols from external to external weak to allow dropping of some targets during linking. llvm-svn: 338413
* [OPENMP] Prevent problems with linking of the static variables.Alexey Bataev2018-07-311-0/+13
| | | | | | No need to change the linkage, we can avoid the problem using special variable. That points to the original variable and, thus, prevent some of the optimizations that might break the compilation. llvm-svn: 338399
* Revert "Add a definition for FieldSize that seems to make sense here."Eric Christopher2018-07-301-1/+0
| | | | | | This reverts commit r338327, the problem was previously fixed in r338321. llvm-svn: 338328
* Add a definition for FieldSize that seems to make sense here.Eric Christopher2018-07-301-0/+1
| | | | | | This could be sunk out of the if statements, but fix the warning for now. llvm-svn: 338327
* Fix use of uninitialized variable in r338299Scott Linder2018-07-301-1/+1
| | | | llvm-svn: 338321
* [DebugInfo][OpenCL] Generate correct block literal debug info for OpenCLScott Linder2018-07-301-34/+48
| | | | | | | | | OpenCL block literal structs have different fields which are now correctly identified in the debug info. Differential Revision: https://reviews.llvm.org/D49930 llvm-svn: 338299
* Remove trailing spaceFangrui Song2018-07-3038-486/+486
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-302-16/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
* [ARM, AArch64]: Use unadjusted alignment when passing composites as argumentsMomchil Velikov2018-07-301-5/+14
| | | | | | | | | | | | | | | | | | The "Procedure Call Procedure Call Standard for the ARM® Architecture" (https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that composite types are passed according to their "natural alignment", i.e. the alignment before alignment adjustment on the entire composite is applied. The same applies for AArch64 ABI. Clang, however, used the adjusted alignment. GCC already implements the ABI correctly. With this patch Clang becomes compatible with GCC and passes such arguments in accordance with AAPCS. Differential Revision: https://reviews.llvm.org/D46013 llvm-svn: 338279
* [mips64][clang] Provide the signext attribute for i32 return valuesStefan Maksimovic2018-07-301-2/+8
| | | | | | | | Additional info: see r338019. Differential Revision: https://reviews.llvm.org/D49289 llvm-svn: 338239
* Revert r337456: [CodeGen] Disable aggressive structor optimizations at -O0, ↵Chandler Carruth2018-07-291-14/+4
| | | | | | | | | | | | | | | | | | | | | | | | take 3 This commit increases the number of sections and overall output size of .o files by 10% and sometimes a bit more. This alone is challenging for some users, but it also appears to trigger an as-yet unexplained behavior in the Gold linker where the memory usage increases considerably more than 10% (we think). The increase is also frustrating because in many (if not all) cases we end up with almost all of the growth coming from the ELF overhead of -ffunction-sections and such, not from actual extra code being emitted. Richard Smith and Eric Christopher are both going to investigate this and try to get to the bottom of what is triggering this and whether the kinds of increases here are sustainable or what options we might have to minimize the impact they have. However, this is currently breaking a pretty large number of our users' builds so reverting it while we sort out how to make progress here. I've seen a longer and more detailed update to the commit thread. llvm-svn: 338209
* [UBSan] Strengthen pointer checks in 'new' expressionsSerge Pavlov2018-07-284-26/+69
| | | | | | | | | | | | | | | | | | | | With this change compiler generates alignment checks for wider range of types. Previously such checks were generated only for the record types with non-trivial default constructor. So the types like: struct alignas(32) S2 { int x; }; typedef __attribute__((ext_vector_type(2), aligned(32))) float float32x2_t; did not get checks when allocated by 'new' expression. This change also optimizes the checks generated for the arrays created in 'new' expressions. Previously the check was generated for each invocation of type constructor. Now the check is generated only once for entire array. Differential Revision: https://reviews.llvm.org/D49589 llvm-svn: 338199
* [CUDA][HIP] Allow function-scope static const variableYaxun Liu2018-07-281-0/+4
| | | | | | | | | | | | | | | | | | | | | | CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__ function, only __shared__ variables or variables without any device memory qualifiers may be declared with static storage class. It is unclear how a function-scope non-const static variable without device memory qualifier is implemented, therefore only static const variable without device memory qualifier is allowed, which can be emitted as a global variable in constant address space. Currently clang only allows function-scope static variable with __shared__ qualifier. This patch also allows function-scope static const variable without device memory qualifier and emits it as a global variable in constant address space. Differential Revision: https://reviews.llvm.org/D49931 llvm-svn: 338188
* [AST] Add a convenient getter from QualType to RecordDeclGeorge Karpenkov2018-07-282-5/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D49951 llvm-svn: 338187
* [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structsSanjin Sijaric2018-07-261-0/+1
| | | | | | | | | | | | | | | | | Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
* [COFF, ARM64] Decide when to mark struct returns as SRetMandeep Singh Grang2018-07-262-1/+14
| | | | | | | | | | | | | | | | Summary: Refer the MS ARM64 ABI Convention for the behavior for struct returns: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions#return-values Reviewers: mstorsjo, compnerd, rnk, javed.absar, yinma, efriedma Reviewed By: rnk, efriedma Subscribers: haripul, TomTan, yinma, efriedma, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D49464 llvm-svn: 338050
* [RISCV] Add support for interrupt attributeAna Pazos2018-07-261-0/+21
| | | | | | | | | | | | | | | | | | | Summary: Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV targets. Permissible values for this parameter are user, supervisor, and machine. If there is no parameter, then it defaults to machine. Reference: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html Based on initial patch by Zhaoshi Zheng. Reviewers: asb, aaron.ballman Reviewed By: asb, aaron.ballman Subscribers: rkruppe, the_o, aaron.ballman, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D48412 llvm-svn: 338045
* [CodeGen][ObjC] Make block copy/dispose helper functions exception-safe.Akira Hatanaka2018-07-263-61/+103
| | | | | | | | | | | | | When an exception is thrown in a block copy helper function, captured objects that have previously been copied should be destructed or released. Similarly, captured objects that are yet to be released should be released when an exception is thrown in a dispose helper function. rdar://problem/42410255 Differential Revision: https://reviews.llvm.org/D49718 llvm-svn: 338041
* [OPENMP] ThreadId in serialized parallel regions is 0.Alexey Bataev2018-07-252-9/+16
| | | | | | | | The first argument for the parallel outlined functions, called as serialized parallel regions, should be a pointer to the global thread id that always is 0. llvm-svn: 337957
* CodeGen: use non-zero memset when possible for automatic variablesJF Bastien2018-07-251-26/+141
| | | | | | | | | | | | | | | | | Summary: Right now automatic variables are either initialized with bzero followed by a few stores, or memcpy'd from a synthesized global. We end up encountering a fair amount of code where memcpy of non-zero byte patterns would be better than memcpy from a global because it touches less memory and generates a smaller binary. The optimizer could reason about this, but it's not really worth it when clang already knows. This code could definitely be more clever but I'm not sure it's worth it. In particular we could track a histogram of bytes seen and figure out (as we do with bzero) if a memset could be followed by a handful of stores. Similarly, we could tune the heuristics for GlobalSize, but using the same as for bzero seems conservatively OK for now. <rdar://problem/42563091> Reviewers: dexonsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49771 llvm-svn: 337887
* Revert "[DebugInfo] Generate debug information for labels. (Fix PR37395)"Shiva Chen2018-07-243-39/+0
| | | | | | This reverts commit 4288dd3bf082482e02c8a044c611c18168cb0180. llvm-svn: 337803
* [DebugInfo] Generate debug information for labels. (Fix PR37395)Shiva Chen2018-07-243-0/+39
| | | | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. Differential Revision: https://reviews.llvm.org/D45045 Patch by Hsiangkai Wang. llvm-svn: 337800
* Borrow visibility from __fundamental_type_info for generated fundamental ↵Thomas Anderson2018-07-241-60/+67
| | | | | | | | | | | | type infos This is necessary so the clang gives hidden visibility to fundamental types when -fvisibility=hidden is passed. Fixes https://bugs.llvm.org/show_bug.cgi?id=35066 Differential Revision: https://reviews.llvm.org/D49109 llvm-svn: 337788
* Support lifetime-extension of conditional temporaries.Richard Smith2018-07-233-109/+148
| | | | llvm-svn: 337767
* [CodeGen] Record if a C++ record is a trivial typeAaron Smith2018-07-231-0/+4
| | | | | | | | | | | | | | Summary: This has a dependence on D45122 Reviewers: rnk, zturner, llvm-commits, aleksandr.urakov Reviewed By: rnk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D45124 llvm-svn: 337736
* [NEON] Fix support for vrndi_f32(), vrndiq_f32() and vrndns_f32() intrinsicsIvan A. Kosarev2018-07-231-6/+13
| | | | | | | | | | This patch adds support for vrndi_f32() and vrndiq_f32() intrinsics in AArch32 mode and for vrndns_f32() intrinsic in AArch64 mode. Differential Revision: https://reviews.llvm.org/D48829 llvm-svn: 337690
* [HIP] Support -fcuda-flush-denormals-to-zero for amdgcnYaxun Liu2018-07-212-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D48287 llvm-svn: 337639
OpenPOWER on IntegriCloud