Summary: This is the clang part of the initial implementation to support Windows ARM64 COFF format.
Reviewers: ruiu, t.p.northover, rnk, compnerd
Reviewed By: ruiu, compnerd
Subscribers: aemerson, kristof.beyls, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D34706
llvm-svn: 306489
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.
More information:
https://github.com/zhmu/ananas/https://rink.nu/projects/ananas.html
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D32936
llvm-svn: 306239
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
This reverts commit r305399.
This breaks a build in libcxx:
libcxx/src/system_error.cpp:90:16: error: assigning to 'int' from incompatible type 'char *'
if ((ret = ::strerror_r(ev, buffer, strerror_buff_size)) != 0) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Which makes sense according to:
https://linux.die.net/man/3/strerror_r
Not entirely sure how this needs to be fixed.
llvm-svn: 305456
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
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
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
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
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
The WebAssembly threads proposal has changed such that C++
implementations can now declare that atomics up to 64 bits are
"lock free" in C++'s terms.
llvm-svn: 304859
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
Rationale: OpenCL kernels are called via an explicit runtime API
with arguments set with clSetKernelArg(), not as normal sub-functions.
Return SPIR_KERNEL by default as the kernel calling convention to ensure
the fingerprint is fixed such way that each OpenCL argument gets one
matching argument in the produced kernel function argument list to enable
feasible implementation of clSetKernelArg() with aggregates etc. In case
we would use the default C calling conv here, clSetKernelArg() might
break depending on the target-specific conventions; different targets
might split structs passed as values to multiple function arguments etc.
https://reviews.llvm.org/D33639
llvm-svn: 304389
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
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
A recent change requires opencl triple environment for compiling OpenCL
program, which causes regressions in libclc.
This patch fixes that. Instead of deducing language based on triple
environment, it checks LangOptions.
Differential Revision: https://reviews.llvm.org/D33445
llvm-svn: 303644
Alloca always returns a pointer in alloca address space, which may
be different from the type defined by the language. For example,
in C++ the auto variables are in the default address space. Therefore
cast alloca to the expected address space when necessary.
Differential Revision: https://reviews.llvm.org/D32248
llvm-svn: 303370
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Differential Revision: https://reviews.llvm.org/D32770
llvm-svn: 302418
Summary:
When the function is compiled with soft-float or on CPU with no FPU, we
don't need to diagnose for a call from an ISR to a regular function.
Reviewers: jroelofs, eli.friedman
Reviewed By: jroelofs
Subscribers: aemerson, rengolin, javed.absar, cfe-commits
Differential Revision: https://reviews.llvm.org/D32918
llvm-svn: 302274
For OpenCL, the private address space qualifier is 0 in AST. Before this change, 0 address space qualifier
is always mapped to target address space 0. As now target private address space is specified by
alloca address space in data layout, address space qualifier 0 needs to be mapped to alloca addr space specified by the data layout.
This change has no impact on targets whose alloca addr space is 0.
With contributions from Matt Arsenault, Tony Tye and Wen-Heng (Jack) Chung
Differential Revision: https://reviews.llvm.org/D31404
llvm-svn: 299965
Change constant address space from 4 to 2 for the new address space mapping in Clang.
Differential Revision: https://reviews.llvm.org/D31771
llvm-svn: 299691
For target environment amdgiz and amdgizcl (giz means Generic Is Zero), AMDGPU will use new address space mapping where generic address space is 0 and private address space is 5. The data layout is also changed correspondingly.
Differential Revision: https://reviews.llvm.org/D31210
llvm-svn: 298767
This typically is only for a new enough linker (bfd >= 2.16.2 or gold), but
our ppc suppport post-dates this and it should work on all linux platforms. It
is guaranteed to work on all elfv2 platforms.
llvm-svn: 298765
and into TargetInfo::adjust so that it gets called in more places
throughout the compiler (AST serialization in particular).
Should fix PPC modules after removing of faltivec.
llvm-svn: 298487
The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.
Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.
llvm-svn: 298449
We can't actually pretend that 0 is valid for address space 0.
r295877 added a workaround to stop allocating user objects
there, so we can use 0 as the invalid pointer.
Some of the tests seemed to be using private as the non-0 null
test address space, so add copies using local to make sure
this is still stressed.
llvm-svn: 297659
Summary:
Historically, NetBSD, FreeBSD and OpenBSD have defined the macro ABICALLS in
the preprocessor when -mabicalls is in effect.
Mainline GCC later defined __mips_abicalls when -mabicalls is in effect.
This patch teaches the preprocessor to define these macros when appropriate.
NetBSD does not require the ABICALLS macro.
This resolves PR/31694.
Thanks to Sean Bruno for highlighting this issue!
Reviewers: slthakur, seanbruno
Reviewed By: seanbruno
Subscribers: joerg, brad, emaste, seanbruno, cfe-commits
Differential Revision: https://reviews.llvm.org/D29032
llvm-svn: 295728
Summary:
The -mmcu option for GCC sets macros like __AVR_ATmega328P__ (with the trailing
underscores), be sure to include these underscores for Clangs -mcpu option.
See "AVR Built-in Macros" in https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
Reviewers: jroelofs, dylanmckay
Reviewed By: jroelofs, dylanmckay
Subscribers: efriedma, cfe-commits
Differential Revision: https://reviews.llvm.org/D29817
llvm-svn: 294869
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 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
This is a followup change to add v7ve support to clang for gcc
compatibility. Please see r294661.
Patch by Manoj Gupta.
Differential Revision: https://reviews.llvm.org/D29773
llvm-svn: 294662
1. Adds the command line flag for clzero.
2. Includes the clzero flag under znver1.
3. Defines the macro for clzero.
4. Adds a new file which has the intrinsic definition for clzero instruction.
Patch by Ganesh Gopalasubramanian with some additional tests from me.
Differential revision: https://reviews.llvm.org/D29386
llvm-svn: 294559
This feature flag indicates that the processor has support for removing certain instructions from user mode software. But the feature flag by itself doesn't indicate if the support is enabled in the OS. The affected instructions aren't even instructions the compiler would emit. So I don't think think this feature flag should be in the compiler.
llvm-svn: 294414
GCC 7 will predefine two new macros on s390x:
- __ARCH__ indicates the ISA architecture level
- __VX__ indicates that the vector facility is available
This adds those macros to clang as well to ensure continued
compatibility with GCC.
llvm-svn: 294197
Summary:
This tells clang about all of the different AVR microcontrollers.
It also adds code to define the correct preprocessor macros for each
device.
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, cfe-commits
Differential Revision: https://reviews.llvm.org/D28346
llvm-svn: 294177
Summary:
Previously the method would simply return false, causing every single
inline assembly constraint to trigger a compile error.
This adds inline assembly constraint support for the AVR target.
This patch is derived from the code in
AVRISelLowering::getConstraintType.
More details can be found on the AVR-GCC reference wiki
http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
Reviewers: jroelofs, asl
Reviewed By: asl
Subscribers: asl, ahatanak, saaadhu, cfe-commits
Differential Revision: https://reviews.llvm.org/D28344
llvm-svn: 294176
GCC does not generate `__unix` nor `unix` macros. The latter already
intrudes into the user's namespace and should be avoided. Use the
canonical spelling of `__unix__` across all the targets.
llvm-svn: 294148
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
Summary:
When compiling device code, we may still see host code with explicit
calling conventions. NVPTX needs to claim that it supports these CCs,
so that (a) we don't raise noisy warnings, and (b) we don't break
existing code which relies on the existence of these CCs when
specializing templates. (If a CC doesn't exist, clang ignores it, so
two template specializations which are different only insofar as one
specifies a CC are considered identical and therefore are an error if
that CC is not supported.)
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28323
llvm-svn: 291136
Summary:
CUDA lets users share structs between the host and device, so for that
and other reasons, primitive types such as ptrdiff_t should be the same
on both sides of the compilation.
Our code to do this wasn't entirely successful. In particular, we did a
bunch of work during the NVPTXTargetInfo constructor, only to override
it in the NVPTX{32,64}TargetInfo constructors. It worked well enough on
Linux and Mac, but Windows is LLP64, which is different enough to break
it.
This patch removes the NVPTX{32,64}TargetInfo classes entirely and fixes
the bug described above.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28322
llvm-svn: 291135
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Reviewers: rsmith, dylanmckay, cfe-commits, rengolin
Subscribers: rengolin, jroelofs, wdng
Differential Revision: https://reviews.llvm.org/D27123
llvm-svn: 291082
According to extended asm syntax, a case where the clobber list includes a variable from the inputs or outputs should be an error - conflict.
for example:
const long double a = 0.0;
int main()
{
char b;
double t1 = a;
__asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
return 0;
}
This should conflict with the output - t1 which is st, and st which is st aswell.
The patch fixes it.
Commit on behald of Ziv Izhar.
Differential Revision: https://reviews.llvm.org/D15075
llvm-svn: 290539
Michael Zuckerman