summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/target-data.c
Commit message (Collapse)AuthorAgeFilesLines
* AArch64: add arm64_32 support to Clang.Tim Northover2019-11-121-0/+4
|
* [SystemZ] Support z15 processor nameUlrich Weigand2019-09-201-0/+2
| | | | | | | | | | The recently announced IBM z15 processor implements the architecture already supported as "arch13" in LLVM. This patch adds support for "z15" as an alternate architecture name for arch13. Corrsponding LLVM support was committed as rev. 372435. llvm-svn: 372436
* Reland "Change the X86 datalayout to add three address spacesAmy Huang2019-09-101-7/+7
| | | | | | | | | | for 32 bit signed, 32 bit unsigned, and 64 bit pointers." This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5. Original review at https://reviews.llvm.org/D64931. Review for added fix at https://reviews.llvm.org/D66843. llvm-svn: 371568
* Revert "Change the X86 datalayout to add three address spaces for 32 bit ↵Vlad Tsyrklevich2019-08-281-7/+7
| | | | | | | | | signed," This reverts commit r370083 because it caused check-lld failures on sanitizer-x86_64-linux-fast. llvm-svn: 370142
* Change the X86 datalayout to add three address spaces for 32 bit signed,Amy Huang2019-08-271-7/+7
| | | | | | 32 bit unsigned, and 64 bit pointers. llvm-svn: 370083
* [SystemZ] Add support for new cpu architecture - arch13Ulrich Weigand2019-07-121-0/+2
| | | | | | | | | | | | | | | | | This patch series adds support for the next-generation arch13 CPU architecture to the SystemZ backend. This includes: - Basic support for the new processor and its features. - Support for low-level builtins mapped to new LLVM intrinsics. - New high-level intrinsics in vecintrin.h. - Indicate support by defining __VEC__ == 10303. Note: No currently available Z system supports the arch13 architecture. Once new systems become available, the official system name will be added as supported -march name. llvm-svn: 365933
* [AMDGPU] Add the missing clang change of the experimental buffer fat pointerMichael Liao2019-03-181-2/+2
| | | | llvm-svn: 356385
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-081-5/+5
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355685
* Rollback of rL355585.Mitch Phillips2019-03-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduces memory leak in FunctionTest.GetPointerAlignment that breaks sanitizer buildbots: ``` ================================================================= ==2453==ERROR: LeakSanitizer: detected memory leaks Direct leak of 128 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x16936bc in llvm::User::operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/User.cpp:151:19 #2 0x7c3fe9 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:12 #3 0x7c3fe9 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #4 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #5 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #6 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #7 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #8 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #9 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #10 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #11 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #12 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #13 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) Indirect leak of 40 byte(s) in 1 object(s) allocated from: #0 0x610428 in operator new(unsigned long) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/projects/compiler-rt/lib/asan/asan_new_delete.cc:105 #1 0x151be6b in make_unique<llvm::ValueSymbolTable> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/ADT/STLExtras.h:1349:29 #2 0x151be6b in llvm::Function::Function(llvm::FunctionType*, llvm::GlobalValue::LinkageTypes, unsigned int, llvm::Twine const&, llvm::Module*) /b/sanitizer-x86_64-linux-bootstrap/build/llvm/lib/IR/Function.cpp:241 #3 0x7c4006 in Create /b/sanitizer-x86_64-linux-bootstrap/build/llvm/include/llvm/IR/Function.h:144:16 #4 0x7c4006 in (anonymous namespace)::FunctionTest_GetPointerAlignment_Test::TestBody() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/unittests/IR/FunctionTest.cpp:136 #5 0x1a836a0 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #6 0x1a836a0 in testing::Test::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #7 0x1a85c55 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #8 0x1a870d0 in testing::TestCase::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #9 0x1aa5b84 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #10 0x1aa4d30 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc #11 0x1aa4d30 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #12 0x1a6b656 in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #13 0x1a6b656 in main /b/sanitizer-x86_64-linux-bootstrap/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #14 0x7f5af37a22e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) SUMMARY: AddressSanitizer: 168 byte(s) leaked in 2 allocation(s). ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/11358/steps/check-llvm%20asan/logs/stdio for more information. Also introduces use-of-uninitialized-value in ConstantsTest.FoldGlobalVariablePtr: ``` ==7070==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x14e703c in User /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 #1 0x14e703c in Constant /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/Constant.h:44 #2 0x14e703c in llvm::GlobalValue::GlobalValue(llvm::Type*, llvm::Value::ValueTy, llvm::Use*, unsigned int, llvm::GlobalValue::LinkageTypes, llvm::Twine const&, unsigned int) /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalValue.h:78 #3 0x14e5467 in GlobalObject /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/GlobalObject.h:34:9 #4 0x14e5467 in llvm::GlobalVariable::GlobalVariable(llvm::Type*, bool, llvm::GlobalValue::LinkageTypes, llvm::Constant*, llvm::Twine const&, llvm::GlobalValue::ThreadLocalMode, unsigned int, bool) /b/sanitizer-x86_64-linux-fast/build/llvm/lib/IR/Globals.cpp:314 #5 0x6938f1 in llvm::(anonymous namespace)::ConstantsTest_FoldGlobalVariablePtr_Test::TestBody() /b/sanitizer-x86_64-linux-fast/build/llvm/unittests/IR/ConstantsTest.cpp:565:18 #6 0x1a240a1 in HandleExceptionsInMethodIfSupported<testing::Test, void> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #7 0x1a240a1 in testing::Test::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474 #8 0x1a26d26 in testing::TestInfo::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11 #9 0x1a2815f in testing::TestCase::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28 #10 0x1a43de8 in testing::internal::UnitTestImpl::RunAllTests() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43 #11 0x1a42c47 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc #12 0x1a42c47 in testing::UnitTest::Run() /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257 #13 0x1a0dfba in RUN_ALL_TESTS /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46 #14 0x1a0dfba in main /b/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:50 #15 0x7f2081c412e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #16 0x4dff49 in _start (/b/sanitizer-x86_64-linux-fast/build/llvm_build_msan/unittests/IR/IRTests+0x4dff49) SUMMARY: MemorySanitizer: use-of-uninitialized-value /b/sanitizer-x86_64-linux-fast/build/llvm/include/llvm/IR/User.h:79:5 in User ``` See http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30222/steps/check-llvm%20msan/logs/stdio for more information. llvm-svn: 355616
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-071-5/+5
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355585
* Revert "[IR][ARM] Add function pointer alignment to datalayout"Mitch Phillips2019-03-061-5/+5
| | | | | | | | | | | | | This reverts commit 2391bfca97290181ae65796ea6da135d1b6d037b. This reverts rL355522 (https://reviews.llvm.org/D57335). Kills buildbots that use '-Werror' with the following error: /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm/lib/IR/Value.cpp:657:7: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] See buildbots http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/30200/steps/check-llvm%20asan/logs/stdio for more information. llvm-svn: 355537
* [IR][ARM] Add function pointer alignment to datalayoutMichael Platings2019-03-061-5/+5
| | | | | | | | | Use this feature to fix a bug on ARM where 4 byte alignment is incorrectly assumed. Differential Revision: https://reviews.llvm.org/D57335 llvm-svn: 355522
* [clang][ARC] Add ARCTargetInfoTatyana Krasnukha2018-11-271-0/+4
| | | | | | | | Based-on-patch-by: Pete Couperus <petecoup@synopsys.com> Differential Revision: https://reviews.llvm.org/D53100 llvm-svn: 347699
* [driver][mips] Support MIPS R6 target triplesSimon Atanasyan2018-10-161-0/+20
| | | | | | | | | | | | | | | | This change adds support for the following MIPS target triples: mipsisa32r6-linux-gnu mipsisa32r6el-linux-gnu mipsisa64r6-linux-gnuabi64 mipsisa64r6el-linux-gnuabi64 mipsisa64r6-linux-gnuabin32 mipsisa64r6el-linux-gnuabin32 Patch by Yun Qiang Su. Differential revision: https://reviews.llvm.org/D50850 llvm-svn: 344608
* [mips] Group similar commands in the test case. NFCSimon Atanasyan2018-10-161-8/+4
| | | | llvm-svn: 344583
* [mips] Fix handling of GNUABIN32 environment in a target tripleSimon Atanasyan2018-10-151-0/+12
| | | | | | | | | | | | The `GNUABIN32` environment in a target triple implies using the N32 ABI. This patch adds support for this environment and switches on N32 ABI if necessary. Patch by Patch by YunQiang Su. Differential revision: https://reviews.llvm.org/D51464 llvm-svn: 344570
* [PPC] Remove Darwin support from POWER backend.Kit Barton2018-08-271-8/+0
| | | | | | | | | | | | | | This patch removes uses of the Darwin ABI for PowerPC related test cases. This is the first step in removing Darwin support from the POWER backend. clang/test/CodeGen/darwin-ppc-varargs.c was deleted because it was a darwin/ppc specific test case. All other tests were updated to remove the darwin/ppc specific invocation. Phabricator Review: https://reviews.llvm.org/D50989. llvm-svn: 340770
* AMDGPU: Update datalayout for stack alignmentMatt Arsenault2018-03-271-4/+4
| | | | llvm-svn: 328657
* [AMDGPU] Change constant addr space to 4Yaxun Liu2018-02-131-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D43171 llvm-svn: 325031
* AMDGPU: Update for datalayout changeMatt Arsenault2018-02-091-2/+2
| | | | llvm-svn: 324748
* [AMDGPU] Switch to the new addr space mapping by defaultYaxun Liu2018-02-021-4/+4
| | | | | | | | This requires corresponding llvm change. Differential Revision: https://reviews.llvm.org/D40956 llvm-svn: 324102
* [NVPTX] Add lowering of i128 params.Artem Belevich2017-07-201-2/+2
| | | | | | | | | | | | | | | | | The patch adds support of i128 params lowering. The changes are quite trivial to support i128 as a "special case" of integer type. With this patch, we lower i128 params the same way as aggregates of size 16 bytes: .param .b8 _ [16]. Currently, NVPTX can't deal with the 128 bit integers: * in some cases because of failed assertions like ValVTs.size() == OutVals.size() && "Bad return value decomposition" * in other cases emitting PTX with .i128 or .u128 types (which are not valid [1]) [1] http://docs.nvidia.com/cuda/parallel-thread-execution/index.html#fundamental-types Differential Revision: https://reviews.llvm.org/D34555 Patch by: Denys Zariaiev (denys.zariaiev@gmail.com) llvm-svn: 308675
* [SystemZ] Add support for IBM z14 processor (1/3)Ulrich Weigand2017-07-171-0/+4
| | | | | | | | | | | This patch series adds support for the IBM z14 processor. This part includes: - Basic support for the new processor and its features. - Support for low-level builtins mapped to new LLVM intrinsics. Support for the -fzvector extension to vector float and the new high-level vector intrinsics is provided by separate patches. llvm-svn: 308197
* [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
* Temporarily revert "For X86-64 linux and PPC64 linux align int128 to 16 bytes."Eric Christopher2017-02-101-2/+2
| | | | | | | | | until we can get better TargetMachine::isCompatibleDataLayout to compare - otherwise we can't code generate existing bitcode without a string equality data layout. This reverts commit r294703. llvm-svn: 294708
* For X86-64 linux and PPC64 linux align int128 to 16 bytes.Eric Christopher2017-02-101-2/+2
| | | | | | | | | | For other platforms we should find out what they need and likely make the same change, however, a smaller additional change is easier for platforms we know have it specified in the ABI. clang support for r294702 llvm-svn: 294703
* target-data test update for TCE and TCELEPekka Jaaskelainen2016-11-161-1/+5
| | | | llvm-svn: 287115
* [SystemZ] Add -march=archX aliasesUlrich Weigand2016-10-311-0/+2
| | | | | | | | | | | | | | | For compatibility with other compilers on the platform, allow specifying levels of the z/Architecture instead of model names with -march. In particular, the following aliases are now supported: -march=arch8 equals -march=z10 -march=arch9 equals -march=z196 -march=arch10 equals -march=zEC12 -march=arch11 equals -march=z13 This parallels the equivalent (and prerequisite) LLVM change in r285577. llvm-svn: 285578
* [mips] Correct label prefixes for N32 and N64.Daniel Sanders2016-07-191-4/+4
| | | | | | | | | | | | | | | | | Summary: N32 and N64 follow the standard ELF conventions (.L) whereas O32 uses its own ($). This fixes the majority of object differences between -fintegrated-as and -fno-integrated-as. Reviewers: sdardis Subscribers: dsanders, sdardis, llvm-commits Differential Revision: https://reviews.llvm.org/D22412 llvm-svn: 275967
* [AArch64] Change the preferred alignment for char and short.Chad Rosier2016-07-071-1/+1
| | | | | | | | This reinstates commits r273280 and r273289. Original Review: http://reviews.llvm.org/D21414. llvm-svn: 274791
* Revert "[aarch64] Update datalayout for aarch64 tests"Chad Rosier2016-07-071-1/+1
| | | | | | | This reverts commit r273289, which was a follow to r273280, which was reverted because the change was not properly approved. llvm-svn: 274767
* [aarch64] Update datalayout for aarch64 testsArtem Belevich2016-06-211-1/+1
| | | | | | This brings the tests in sync with the changes in r273280. llvm-svn: 273289
* AMDGPU: Update datalayout stringMatt Arsenault2016-05-311-2/+2
| | | | llvm-svn: 271297
* [lanai] Add Lanai backend to clang driver.Jacques Pienaar2016-03-281-0/+4
| | | | | | | | | | Changes to clang to add Lanai backend. Adds a new target, ABI and toolchain. General Lanai backend discussion on llvm-dev thread "[RFC] Lanai backend" (http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html). Differential Revision: http://reviews.llvm.org/D17002 llvm-svn: 264655
* [Hexagon] Specify vector alignment in DataLayout stringKrzysztof Parzyszek2016-02-121-1/+1
| | | | | | | | | | | The DataLayout can calculate alignment of vectors based on the alignment of the element type and the number of elements. In fact, it is the product of these two values. The problem is that for vectors of N x i1, this will return the alignment of N bytes, since the alignment of i1 is 8 bits. The vector types of vNi1 should be aligned to N bits instead. Provide explicit alignment for HVX vectors to avoid such complications. llvm-svn: 260680
* [WebAssembly] Add -m:e to the target triple.Dan Gohman2016-01-071-2/+2
| | | | llvm-svn: 257021
* [Hexagon] Update default paths and argumentsKrzysztof Parzyszek2015-12-141-1/+1
| | | | | | | | | - Removed support for hexagonv3 and earlier. - Added handling of hexagonv55 and hexagonv60. - Added handling of target features (hvx, hvx-double). - Updated paths to reflect current directory layout. llvm-svn: 255502
* [WebAssembly] Initial WebAssembly support in clangDan Gohman2015-09-031-0/+8
| | | | | | | | | | This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet finalized, and may change. Differential Revision: http://reviews.llvm.org/D12002 llvm-svn: 246814
* [bpf] add support for BPF backendAlexei Starovoitov2015-06-101-0/+8
| | | | | | add support for bpfel/bpfeb targets llvm-svn: 239496
* [SystemZ] Add support for z13 and its vector facilityUlrich Weigand2015-05-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the z13 architecture type. For compatibility with GCC, a pair of options -mvx / -mno-vx can be used to selectively enable/disable use of the vector facility. When the vector facility is present, we default to the new vector ABI. This is characterized by two major differences: - Vector types are passed/returned in vector registers (except for unnamed arguments of a variable-argument list function). - Vector types are at most 8-byte aligned. The reason for the choice of 8-byte vector alignment is that the hardware is able to efficiently load vectors at 8-byte alignment, and the ABI only guarantees 8-byte alignment of the stack pointer, so requiring any higher alignment for vectors would require dynamic stack re-alignment code. However, for compatibility with old code that may use vector types, when *not* using the vector facility, the old alignment rules (vector types are naturally aligned) remain in use. These alignment rules are not only implemented at the C language level, but also at the LLVM IR level. This is done by selecting a different DataLayout string depending on whether the vector ABI is in effect or not. Based on a patch by Richard Sandiford. llvm-svn: 236531
* Re-commit the test fix that went with r236274Reid Kleckner2015-04-301-2/+2
| | | | llvm-svn: 236276
* Revert most of r236271, leaving only the datalayout change in ↵Reid Kleckner2015-04-301-2/+2
| | | | | | lib/Basic/Targets.cpp llvm-svn: 236274
* Use 4 byte preferred aggregate alignment in datalayout on x86 Win32Reid Kleckner2015-04-301-2/+2
| | | | llvm-svn: 236271
* Add driver support for Native Client SDKDerek Schuff2015-03-301-1/+1
| | | | | | | | | | | | | | Add Tool and ToolChain support for clang to target the NaCl OS using the NaCl SDK for x86-32, x86-64 and ARM. Includes nacltools::Assemble and Link which are derived from gnutools. They are similar to Linux but different enought that they warrant their own class. Also includes a NaCl_TC in ToolChains derived from Generic_ELF with library and include paths suitable for an SDK and independent of the system tools. Differential Revision: http://reviews.llvm.org/D8590 llvm-svn: 233594
* Basic: Update clang to reflect changes made to LLVM datalayoutDavid Majnemer2015-03-171-2/+2
| | | | | | | We now give x86-64 COFF targets a different mangling code, update clang to use it. llvm-svn: 232571
* R600: Use a Southern Islands GPU as the default for the amdgcn targetTom Stellard2015-01-281-0/+5
| | | | llvm-svn: 227315
* R600: Handle amdgcn tripleTom Stellard2015-01-061-1/+1
| | | | | | For now there is no difference between amdgcn and r600. llvm-svn: 225294
* ARM: remove ARM/Thumb distinction for preferred alignment.Tim Northover2014-10-141-2/+2
| | | | | | | | | | | | Thumb1 has legitimate reasons for preferring 32-bit alignment of types i1/i8/i16, since the 16-bit encoding of "add rD, sp, #imm" requires #imm to be a multiple of 4. However, this is a trade-off betweem code size and RAM usage; the DataLayout string is not the best place to represent it even if desired. So this patch removes the extra Thumb requirements, hopefully making ARM and Thumb completely compatible in this respect. llvm-svn: 219735
* ARM: set preferred aggregate alignment to 32 universally.Tim Northover2014-10-141-2/+2
| | | | | | | | | | | Before, ARM and Thumb mode code had different preferred alignments, which could lead to some rather unexpected results. There's justification for reducing it from the default 64-bits (wasted space), but I don't think there is for going below 32-bits. There's no actual ABI change here, just to reassure people. llvm-svn: 219720
* Make sure aggregates are properly alligned on MSP430.Job Noorman2014-09-301-1/+1
| | | | llvm-svn: 218666
OpenPOWER on IntegriCloud