summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen
Commit message (Collapse)AuthorAgeFilesLines
* [Sema] Allow unmarked overloadable functions.George Burgess IV2017-06-272-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch extends the `overloadable` attribute to allow for one function with a given name to not be marked with the `overloadable` attribute. The overload without the `overloadable` attribute will not have its name mangled. So, the following code is now legal: void foo(void) __attribute__((overloadable)); void foo(int); void foo(float) __attribute__((overloadable)); In addition, this patch fixes a bug where we'd accept code with `__attribute__((overloadable))` inconsistently applied. In other words, we used to accept: void foo(void); void foo(void) __attribute__((overloadable)); But we will do this no longer, since it defeats the original purpose of requiring `__attribute__((overloadable))` on all redeclarations of a function. This breakage seems to not be an issue in practice, since the only code I could find that had this pattern often looked like: void foo(void); void foo(void) __attribute__((overloadable)) __asm__("foo"); void foo(int) __attribute__((overloadable)); ...Which can now be simplified by simply removing the asm label and overloadable attribute from the redeclaration of `void foo(void);` Differential Revision: https://reviews.llvm.org/D32332 llvm-svn: 306467
* Update the test comment to clarify the intention of the test.Dehao Chen2017-06-271-9/+9
| | | | llvm-svn: 306434
* [x86] weaken test checks that shouldn't be here in the first placeSanjay Patel2017-06-271-12/+15
| | | | | | | This test would fail after the proposed change in: https://reviews.llvm.org/D34242 llvm-svn: 306433
* Update test for enabling ICP for AutoFDO.Dehao Chen2017-06-271-2/+2
| | | | | | | | | | | | | | Summary: This is the test update patch for https://reviews.llvm.org/D34662 Reviewers: davidxl Reviewed By: davidxl Subscribers: cfe-commits, sanjoy, mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D34663 llvm-svn: 306430
* [inline asm] dot operator while using imm generates wrong ir + asm - clang partMarina Yatsina2017-06-261-0/+6
| | | | | | | | | | | | | | | | | | Inline asm dot operator while using imm generates wrong ir and asm This is the test for the llvm changes committed in revision 306300 This also fixes bugzilla 32987: https://bugs.llvm.org//show_bug.cgi?id=32987 The llvm part of the review that contains the test can be found here: https://reviews.llvm.org/D33039 commit on behald of zizhar Differential Revision: https://reviews.llvm.org/D33040 llvm-svn: 306301
* [MSP430] Fix data layout string.Vadzim Dambrouski2017-06-231-1/+1
| | | | | | | | | | | | | | | | | Summary: Change data layout string so it would be compatible with MSP430 EABI. Depends on D34561 Reviewers: asl, awygle Reviewed By: asl Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34562 llvm-svn: 306161
* SwiftCC: Perform physical layout when computing coercion typesArnold Schwaighofer2017-06-211-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | We need to take type alignment padding into account whe computing physical layouts. The layout must be compatible with the input layout, offsets are defined in terms of offsets within a packed struct which are computed in terms of the alloc size of a type. Usingthe store size we would insert padding for the following type for example: struct { int3 v; long long l; } __attribute((packed)) On x86-64 int3 is padded to int4 alignment. The swiftcc type would be <{ <3 x float>, [4 x i8], i64 }> which is not compatible with <{ <3 x float>, i64 }>. The latter has i64 at offset 16 and the former at offset 20. rdar://32618125 llvm-svn: 305956
* Correct VectorCall x86 (32 bit) behavior for SSE Register AssignmentErich Keane2017-06-211-4/+15
| | | | | | | | | | | | | | | | | | | In running some internal vectorcall tests in 32 bit mode, we discovered that the behavior I'd previously implemented for x64 (and applied to x32) regarding the assignment of SSE registers was incorrect. See spec here: https://msdn.microsoft.com/en-us/library/dn375768.aspx My previous implementation applied register argument position from the x64 version to both. This isn't correct for x86, so this removes and refactors that section. Additionally, it corrects the integer/int-pointer assignments. Unlike x64, x86 permits integers to be assigned independent of position. Finally, the code for 32 bit was cleaned up a little to clarify the intent, as well as given a descriptive comment. Differential Revision: https://reviews.llvm.org/D34455 llvm-svn: 305928
* Support MS builtins using 'long' on LP64 platformsBruno Cardoso Lopes2017-06-213-48/+174
| | | | | | | | | | | | | | | This allows for -fms-extensions to work the same on LP64. For example, _BitScanReverse is expected to be 32-bit, matching Windows/LLP64, even though long is 64-bit on x86_64 Darwin or Linux (LP64). Implement this by adding a new character code 'N', which is 'int' if the target is LP64 and the same 'L' otherwise Differential Revision: https://reviews.llvm.org/D34377 rdar://problem/32599746 llvm-svn: 305875
* Run dos2unix on ms-intrinsics-rotations.c test. NFCBruno Cardoso Lopes2017-06-211-171/+171
| | | | llvm-svn: 305874
* Prevent devirtualization of calls to un-instantiated functions.Sunil Srivastava2017-06-201-0/+59
| | | | | | | | PR 27895 Differential Revision: https://reviews.llvm.org/D22057 llvm-svn: 305862
* [AArch64] ADD ARMv.2-A FP16 vector intrinsicsAbderrazek Zaafrani2017-06-204-355/+1976
| | | | | | Differential Revision: https://reviews.llvm.org/D34161 llvm-svn: 305820
* [Clang] Handle interaction of -pg and no_instrument_function attribute.Manoj Gupta2017-06-191-16/+23
| | | | | | | | | | | | | | | | | | | | | | Summary: Disable generation of counting-function attribute if no_instrument_function attribute is present in function. Interaction between -pg and no_instrument_function is the desired behavior and matches gcc as well. This is required for fixing a crash in Linux kernel when function tracing is enabled. Fixes PR33515. Reviewers: hfinkel, rengolin, srhines, hans Reviewed By: hfinkel Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34357 llvm-svn: 305728
* CodeGen: Cast temporary variable to proper address spaceYaxun Liu2017-06-193-12/+15
| | | | | | | | | | | | | | | | In C++ all variables are in default address space. Previously change has been made to cast automatic variables to default address space. However that is not sufficient since all temporary variables need to be casted to default address space. This patch casts all temporary variables to default address space except those for passing indirect arguments since they are only used for load/store. This patch only affects target having non-zero alloca address space. Differential Revision: https://reviews.llvm.org/D33706 llvm-svn: 305711
* Expand vector oparation to as IR constants, PR28129.Dinar Temirbulatov2017-06-161-0/+48
| | | | llvm-svn: 305551
* [ubsan] PR33081: Skip the standard type checks for volatileVedant Kumar2017-06-161-0/+7
| | | | | | | | | | Skip checks for null dereference, alignment violation, object size violation, and dynamic type violation if the pointer points to volatile data. Differential Revision: https://reviews.llvm.org/D34262 llvm-svn: 305546
* Apply summary-based dead stripping to regular LTO modules with summaries.Peter Collingbourne2017-06-152-2/+11
| | | | | | | | | | | | | | | If a regular LTO module has a summary index, then instead of linking it into the combined regular LTO module right away, add it to the combined summary index and associate it with a special module that represents the combined regular LTO module. Any such modules are linked during LTO::run(), at which time we use the results of summary-based dead stripping to control whether to link prevailing symbols. Differential Revision: https://reviews.llvm.org/D33922 llvm-svn: 305482
* [PPC] Enhance altivec conversion function macros implementation.Tony Jiang2017-06-141-0/+33
| | | | | | | | | | Add checking for the second parameter of altivec conversion builtin to make sure it is compile-time constant int. This patch fixes PR33212: PPC vec_cst useless at -O0 Differential Revision: https://reviews.llvm.org/D34092 llvm-svn: 305401
* Be more strict when checking the -flto option valueYuka Takahashi2017-06-141-2/+4
| | | | | | | | | | | | | | Summary: It seems -flto must be either "thin" or "full". I think the use of containValue is just a typo. Reviewers: ruiu, tejohnson Subscribers: mehdi_amini, inglorion Differential Revision: https://reviews.llvm.org/D34055 llvm-svn: 305392
* Preserve cold attribute for function declsXinliang David Li2017-06-131-0/+10
| | | | | | Differential Revision: http://reviews.llvm.org/D34133 llvm-svn: 305325
* IR: Replace the "Linker Options" module flag with "llvm.linker.options" ↵Peter Collingbourne2017-06-124-15/+5
| | | | | | | | | | named metadata. The new metadata is easier to manipulate than module flags. Differential Revision: https://reviews.llvm.org/D31349 llvm-svn: 305227
* Correct debug info bit offset calculation for big-endian targetsReid Kleckner2017-06-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The change "[CodeView] Implement support for bit fields in Clang" (r274201, https://reviews.llvm.org/rL274201) broke the calculation of bit offsets for the debug info describing bitfields on big-endian targets. Prior to commit r274201 the debug info for bitfields got their offsets from the ASTRecordLayout in CGDebugInfo::CollectRecordFields(), the current field offset was then passed on to CGDebugInfo::CollectRecordNormalField() and used directly in the DIDerivedType. Since commit r274201, the bit offset ending up in the DIDerivedType no longer comes directly from the ASTRecordLayout. Instead CGDebugInfo::CollectRecordNormalField() calls the new method CGDebugInfo::createBitFieldType(), which in turn calls CodeGenTypes::getCGRecordLayout().getBitFieldInfo() to fetch a CGBitFieldInfo describing the field. The 'Offset' member of CGBitFieldInfo is then used to calculate the bit offset of the DIDerivedType. Unfortunately the previous and current method of calculating the bit offset are only equivalent for little endian targets, as CGRecordLowering::setBitFieldInfo() reverses the bit offsets for big endian targets as the last thing it does. A simple reproducer for this error is the following module: struct fields { unsigned a : 4; unsigned b : 4; } flags = {0x0f, 0x1}; Compiled for Mips, with commit r274200 both the DIDerivedType bit offsets on the IR-level and the DWARF information on the ELF-level will have the expected values: the offsets of 'a' and 'b' are 0 and 4 respectively. With r274201 the offsets are switched to 4 and 0. By noting that the static initialization of 'flags' in both cases is the same, we can eliminate a change in record layout as the cause of the change in the debug info. Also compiling this example with gcc, produces the same record layout and debug info as commit r274200. In order to restore the previous function we extend CGDebugInfo::createBitFieldType() to compensate for the reversal done in CGRecordLowering::setBitFieldInfo(). Patch by Frej Drejhammar! Reviewers: cfe-commits, majnemer, rnk, aaboud, echristo, aprantl Reviewed By: rnk, aprantl Subscribers: aprantl, arichardson, frej Differential Revision: https://reviews.llvm.org/D32745 llvm-svn: 305224
* [ubsan] Detect invalid unsigned pointer index expression (clang)Vedant Kumar2017-06-121-15/+57
| | | | | | | | | | | | | | | | | | | | | | | | Adding an unsigned offset to a base pointer has undefined behavior if the result of the expression would precede the base. An example from @regehr: int foo(char *p, unsigned offset) { return p + offset >= p; // This may be optimized to '1'. } foo(p, -1); // UB. This patch extends the pointer overflow check in ubsan to detect invalid unsigned pointer index expressions. It changes the instrumentation to only permit non-negative offsets in pointer index expressions when all of the GEP indices are unsigned. Testing: check-llvm, check-clang run on a stage2, ubsan-instrumented build. Differential Revision: https://reviews.llvm.org/D33910 llvm-svn: 305216
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-1/+6
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* Reapply r304929 [mips] Add runtime options to enable/disable madd/sub.fmtPetar Jovanovic2017-06-071-0/+87
| | | | | | | | | | | | | | | | | The test in r304929 broke multiple buildbots as it expected mips target to be registered and available (which is not necessarily true). Updating the test with this condition. Original commit: [mips] Add runtime options to enable/disable madd.fmt and msub.fmt Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable generation of madd.fmt and similar instructions respectively, as per GCC. Patch by Stefan Maksimovic. llvm-svn: 304953
* Finish revert of "r304929, [mips] Add runtime options to enable/disable ↵Simon Dardis2017-06-071-0/+0
| | | | | | | | madd/sub.fmt" The r304935 missed deleting the test case. llvm-svn: 304936
* Revert r304929 [mips] Add runtime options to enable/disable madd/sub.fmtPetar Jovanovic2017-06-071-86/+0
| | | | | | | | | | | | | | | Revert r304929 since the test broke buildbots. Original commit: [mips] Add runtime options to enable/disable madd.fmt and msub.fmt Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable generation of madd.fmt and similar instructions respectively, as per GCC. Patch by Stefan Maksimovic. llvm-svn: 304935
* [mips] Add runtime options to enable/disable madd.fmt and msub.fmtPetar Jovanovic2017-06-071-0/+86
| | | | | | | | | | | Add options to clang: -mmadd4 and -mno-madd4, use it to enable or disable generation of madd.fmt and similar instructions respectively, as per GCC. Patch by Stefan Maksimovic. Differential Revision: https://reviews.llvm.org/D33401 llvm-svn: 304929
* [CodeGen] Add thumb-mode to target-features for arm/thumb triples.Florian Hahn2017-06-074-22/+53
| | | | | | | | | | | | | | | | | | | | | Summary: The thumb-mode target feature is used to force Thumb or ARM code generation on a per-function basis. Explicitly adding +thumb-mode to functions for thumbxx triples enables mixed ARM/Thumb code generation in places where compilation units with thumbxx and armxx triples are merged together (e.g. the IR linker or LTO). For armxx triples, -thumb-mode is added in a similar fashion. Reviewers: echristo, t.p.northover, kristof.beyls, rengolin Reviewed By: echristo Subscribers: rinon, aemerson, mehdi_amini, javed.absar, cfe-commits Differential Revision: https://reviews.llvm.org/D33448 llvm-svn: 304897
* [ARM] Fix Neon vector type alignment to 64-bitJaved Absar2017-06-071-0/+17
| | | | | | | | | | This is restricted version of patch - https://reviews.llvm.org/D33205 that I reverted as it was leading to ABI breaks on darwin etc. This patch restricts the fix to AAPCS (Android remains 128-bit). Reviewed by: Renato Golin, Stephen Hines Differential Revision: https://reviews.llvm.org/D33786 llvm-svn: 304889
* [ARM] Add support for target("arm") and target("thumb").Florian Hahn2017-06-061-0/+19
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds support for the target("arm") and target("thumb") attributes, which can be used to force the compiler to generated ARM or Thumb code for a function. In LLVM, ARM or Thumb code generation can be controlled by the thumb-mode target feature. But GCC already uses target("arm") and target("thumb"), so we have to substitute "arm" with -thumb-mode and "thumb" with +thumb-mode. Reviewers: echristo, pcc, kristof.beyls Reviewed By: echristo Subscribers: ahatanak, aemerson, javed.absar, kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D33721 llvm-svn: 304781
* Revert "[AArch64] Add ARMv8.2-A FP16 vefctor intrinsics"Vedant Kumar2017-06-023-1859/+232
| | | | | | | | | | | | This reverts commit r304493. It breaks all the Darwin bots: http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental_check/37168 Failure: Failing Tests (2): Clang :: CodeGen/aarch64-v8.2a-neon-intrinsics.c Clang :: CodeGen/arm_neon_intrinsics.c llvm-svn: 304509
* [ThinLTO] Add x86 requires to thin_link_bitcode. NFC.Tim Shen2017-06-021-0/+2
| | | | | | | | | It already specifies the triples, so the intention was to test x86 for now (or then). Differential Revision: https://reviews.llvm.org/D33692 llvm-svn: 304501
* [ThinLTO] Wire up ThinLTO and new PMTim Shen2017-06-011-0/+3
| | | | | | | | | | | | Summary: This patch teaches clang to use and propagate new PM in ThinLTO. Reviewers: davide, chandlerc, tejohnson Subscribers: mehdi_amini, Prazek, inglorion, cfe-commits Differential Revision: https://reviews.llvm.org/D33692 llvm-svn: 304496
* [AArch64] Add ARMv8.2-A FP16 vefctor intrinsicsAbderrazek Zaafrani2017-06-013-232/+1859
| | | | llvm-svn: 304493
* Relax test to try and appease builders. NFC.Vedant Kumar2017-06-011-6/+6
| | | | | | | | | | I'm not sure why, but on some bots, the order of two instructions are swapped (as compared to the output on my machine). Loosen up the CHECK-NEXT directives to deal with this. Failing bot: http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/3097 llvm-svn: 304486
* Don't assume that a store source is a vector type just because the ↵Simon Pilgrim2017-06-011-0/+12
| | | | | | destination is (PR26099) llvm-svn: 304465
* [ubsan] Add a check for pointer overflow UBVedant Kumar2017-06-011-0/+171
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check pointer arithmetic for overflow. For some more background on this check, see: https://wdtz.org/catching-pointer-overflow-bugs.html https://reviews.llvm.org/D20322 Patch by Will Dietz and John Regehr! This version of the patch is different from the original in a few ways: - It introduces the EmitCheckedInBoundsGEP utility which inserts checks when the pointer overflow check is enabled. - It does some constant-folding to reduce instrumentation overhead. - It does not check some GEPs in CGExprCXX. I'm not sure that inserting checks here, or in CGClass, would catch many bugs. Possible future directions for this check: - Introduce CGF.EmitCheckedStructGEP, to detect overflows when accessing structures. Testing: Apart from the added lit test, I ran check-llvm and check-clang with a stage2, ubsan-instrumented clang. Will and John have also done extensive testing on numerous open source projects. Differential Revision: https://reviews.llvm.org/D33305 llvm-svn: 304459
* Enable the ARM Neon intrinsics test by default.Alexander Kornienko2017-05-311-2/+0
| | | | | | | | | | | | The test being marked 'REQUIRES: long-tests' doesn't make sense. It's not the first time the test is broken without being noticed by the committer. If the test is too long, it should be shortened, split in multiple ones or removed altogether. Keeping it as is is actively harmful. (BTW, on my machine `ninja check-clang` takes 90-92 seconds with and without this test. The difference in times is below the spread caused by random factors.) llvm-svn: 304302
* Revert "[ARM] Update long-test after r304201."Alexander Kornienko2017-05-311-618/+618
| | | | | | | | | This reverts commit 304208, since r304201 has been reverted as well. The test needs to be turned on by default to detect breakages earlier. Will commit this change separately. llvm-svn: 304301
* Reverting Neon vector type 64-alignment fixJaved Absar2017-05-304-22/+14
| | | | | | | The patch caused ABI breaks on darwin/others. Reverting to come back with a more restrictive patch. llvm-svn: 304220
* Fixup r304205 - Require PowerPC targetDiana Picus2017-05-301-0/+2
| | | | llvm-svn: 304211
* Fix issue with test that caused bildbot failureJaved Absar2017-05-301-2/+2
| | | | | | | | | | | | These tests did not specify the target. The failure was triggered by change - https://reviews.llvm.org/D33205 http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/7314 which sets vector alignment to 8-byte for arm-targets (except for Android). So, fixing the test to make it target specific. llvm-svn: 304210
* [ARM] Update long-test after r304201.Benjamin Kramer2017-05-301-618/+618
| | | | llvm-svn: 304208
* [PPC] Make altivec conversion function macros.Benjamin Kramer2017-05-301-0/+80
| | | | | | | | | | The second argument must be a constant, otherwise instruction selection will fail. always_inline is not enough for isel to always fold everything away at -O0. Sadly the overloading turned this into a big macro mess. Fixes PR33212. llvm-svn: 304205
* [ARM] Fix Neon vector type alignment to 64-bitJaved Absar2017-05-304-14/+22
| | | | | | | | | | | The maximum alignment for ARM NEON data types should be 64-bits as specified in ARM procedure call standard document Sec. A.2 Notes. This patch fixes it from its current larger natural default values, except for Android (so as not to break existing ABI). Reviewed by: Stephen Hines, Renato Golin. Differential Revision: https://reviews.llvm.org/D33205 llvm-svn: 304201
* Unbreak long test after r304127.Benjamin Kramer2017-05-291-1/+2
| | | | llvm-svn: 304167
* IRGen: Add optnone attribute on function during O0Mehdi Amini2017-05-2940-50/+52
| | | | | | | | | | | Amongst other, this will help LTO to correctly handle/honor files compiled with O0, helping debugging failures. It also seems in line with how we handle other options, like how -fnoinline adds the appropriate attribute as well. Differential Revision: https://reviews.llvm.org/D28404 llvm-svn: 304127
* CodeGen: Define Swift's legal vector types for AArch64, ARMArnold Schwaighofer2017-05-262-0/+17
| | | | | | rdar://32401301 llvm-svn: 304017
* [X86] Adding avx512_vpopcntdq feature set and its intrinsicsOren Ben Simhon2017-05-252-1/+39
| | | | | | | | | | AVX512_VPOPCNTDQ is a new feature set that was published by Intel. The patch represents the Clang side of the addition of six intrinsics for two new machine instructions (vpopcntd and vpopcntq). It also includes the addition of the new feature set. Differential Revision: https://reviews.llvm.org/D33170 llvm-svn: 303857
OpenPOWER on IntegriCloud