| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
PS4 target recognizes the #pragma comment() syntax as in -fms-extensions, but
only handles the case of #pragma comment(lib). This patch adds a warning if any
other arguments are encountered.
This patch also refactors the code in ParsePragma.cpp a little bit to make it
more obvious that some codes are being shared between -fms-extensions and PS4.
llvm-svn: 233015
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On AArch64, the -fallow-half-args-and-returns option is the default.
With it, the half type is considered legal (rather than the i16 used
normally for __fp16), but no operation is, except conversions and
load/stores and such.
The previous behavior was tantamount to saying LangOpts.NativeHalfType
was implied by LangOpts.HalfArgsAndReturns, which isn't true.
Instead, teach the various parts of CodeGen that already know about
half (using the intrinsics or not) about this weird in-between case,
where the "half" type is legal, but operations on it aren't.
This is a smaller intermediate step to the end-goal of removing the
intrinsic, always using "half", and letting the backend legalize.
Builds on r232968.
rdar://20045970, rdar://17468714
Differential Revision: http://reviews.llvm.org/D8367
llvm-svn: 232971
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix the CodeGen so that for types bigger than float, instead of
converting to fp16 via the sequence "InTy -> float -> fp16", we
perform conversions in just one step. This avoids the double
rounding which potentially changes results from a natural
IEEE-754 operation.
rdar://17594379, rdar://17468714
Differential Revision: http://reviews.llvm.org/D4602
Part of: http://reviews.llvm.org/D8367
llvm-svn: 232968
|
| |
|
|
|
|
|
| |
This breaks CodeGen for an internal target. I'll get repro instructions
to you.
llvm-svn: 232930
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
the target-cpu, if different from the triple's cpu, and
target-features as they're written that are passed down from the
driver.
Together with LLVM r232885 this should allow the LTO'ing of binaries
that contain modules compiled with different code generation options
on a subset of architectures with full backend support (x86, powerpc,
aarch64).
llvm-svn: 232888
|
| |
|
|
|
|
|
| |
This corresponds to llvm r232852:
http://reviews.llvm.org/rL232852
llvm-svn: 232857
|
| |
|
|
|
|
| |
This fixes PR22961.
llvm-svn: 232824
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Somehow, we never managed to implement this fully. We could constant
fold it like crazy, including constant folding complex arguments, etc.
But if you actually needed to generate code for it, error.
I've implemented it using the somewhat obvious lowering. Happy for
suggestions on a more clever way to lower this.
Now, what you might ask does this have to do with modules? Fun story. So
it turns out that libstdc++ actually uses __builtin_isinf_sign to
implement std::isinf when in C++98 mode, but only inside of a template.
So if we're lucky, and we never instantiate that, everything is good.
But once we try to instantiate that template function, we need this
builtin. All of my customers at least are using C++11 and so they never
hit this code path.
But what does that have to do with modules? Fun story. So it turns out
that with modules we actually observe a bunch of bugs in libstdc++ where
their <cmath> header clobbers things exposed by <math.h>. To fix these,
we have to provide global function definitions to replace the macros
that C99 would have used. And it turns out that ::isinf needs to be
implemented using the exact semantics used by the C++98 variant of
std::isinf. And so I started to fix this bug in libstdc++ and ceased to
be able to compile libstdc++ with Clang.
The yaks are legion.
llvm-svn: 232778
|
| |
|
|
|
|
|
| |
We now give x86-64 COFF targets a different mangling code, update clang
to use it.
llvm-svn: 232571
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
location data is available. If pragma handling wants to look up the
position, it finds the LLVM buffer and wants to compare it with the
special built-in buffer, failing badly. Extend to the special handling
of the built-in buffer to also check for the inline asm buffer. Expect
only a single asm buffer. Sort it between the built-in buffers and the
normal file buffers.
Fixes the assert part of PR 22576.
llvm-svn: 232389
|
| |
|
|
| |
llvm-svn: 232237
|
| |
|
|
|
|
|
| |
In preparation for recommit of revision 232190, change tests so that they
are resilient to operands being commuted by the reassociate pass.
llvm-svn: 232206
|
| |
|
|
| |
llvm-svn: 232187
|
| |
|
|
|
|
| |
gep operator changes coming soon
llvm-svn: 232185
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is nearly identical to the v*f128_si256 parts of r231792 and r232052.
AVX2 introduced proper integer variants of the hacked integer insert/extract
C intrinsics that were created for this same functionality with AVX1.
This should complete the front end fixes for insert/extract128 intrinsics.
Corresponding LLVM patch to follow.
llvm-svn: 232109
|
| |
|
|
|
|
|
|
|
|
|
| |
This is very much like D8088 (checked in at r231792).
Now that we've replaced the vinsertf128 intrinsics,
do the same for their extract twins.
Differential Revision: http://reviews.llvm.org/D8275
llvm-svn: 232052
|
| |
|
|
|
|
| |
__builtin_longjmp to Sema as requested by John McCall.
llvm-svn: 231986
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Support for the QPX vector instruction set, used on the IBM BG/Q supercomputer,
has recently been added to the LLVM PowerPC backend. This vector instruction
set requires some ABI modifications because the ABI on the BG/Q expects
<4 x double> vectors to be provided with 32-byte stack alignment, and to be
handled as native vector types (similar to how Altivec vectors are handled on
mainline PPC systems). I've named this ABI variant elfv1-qpx, have made this
the default ABI when QPX is supported, and have updated the ABI handling code
to provide QPX vectors with the correct stack alignment and associated
register-assignment logic.
llvm-svn: 231960
|
| |
|
|
|
|
|
|
|
|
| |
POWER8.
These are the Clang-related changes for the instructions added to LLVM in http://reviews.llvm.org/D7959.
Phabricator review: http://reviews.llvm.org/D8041
llvm-svn: 231931
|
| |
|
|
|
|
|
|
|
| |
This was using the driver to test LLVM.
I checked that disabling the code path that the test was testing causes
llvm tests to fail.
llvm-svn: 231895
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to replace as much custom x86 shuffling via intrinsics
as possible because pushing the code down the generic shuffle
optimization path allows for better codegen and less complexity
in LLVM.
This is the sibling patch for the LLVM half of this change:
http://reviews.llvm.org/D8086
Differential Revision: http://reviews.llvm.org/D8088
llvm-svn: 231792
|
| |
|
|
|
|
| |
one, for -Asserts for now. They were introduced in r231711.
llvm-svn: 231717
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent.
This is a recommit of r231150, reverted in r231409. Turns out
that -fsanitize=shift-base check implementation only works if the
shift exponent is valid, otherwise it contains undefined behavior
itself.
Make sure we check that exponent is valid before we proceed to
check the base. Make sure that we actually report invalid values
of base or exponent if -fsanitize=shift-base or
-fsanitize=shift-exponent is specified, respectively.
llvm-svn: 231711
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When passing a type with large alignment byval, we were specifying the type's
alignment rather than the alignment that the backend is actually capable of
producing (ABIAlign).
This would be OK (if odd) assuming the backend dealt with it prooperly,
unfortunately it doesn't and trying to pass types with "byval align 16" can
cause it to set fp incorrectly and trash the stack during the prologue. I'll be
fixing that in a separate patch, but Clang should still be emitting IR that's
as close to its intent as possible.
rdar://20059039
llvm-svn: 231706
|
| |
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent."
It's not that easy. If we're only checking -fsanitize=shift-base we
still need to verify that exponent has sane value, otherwise
UBSan-inserted checks for base will contain undefined behavior
themselves.
llvm-svn: 231409
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Temporary XFAIL's until patches done.
Reviewers: echristo, adasgupt, colinl
Reviewed By: colinl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8044
llvm-svn: 231318
|
| |
|
|
|
|
| |
Review: http://reviews.llvm.org/D7951
llvm-svn: 231291
|
| |
|
|
|
|
|
|
| |
Opt in Win64 to supporting sjlj lowering. We have the backend lowering,
so I think this was just an oversight because WinX86_64TargetCodeGenInfo
doesn't inherit from X86_64TargetCodeGenInfo.
llvm-svn: 231280
|
| |
|
|
| |
llvm-svn: 231247
|
| |
|
|
|
|
|
| |
__builtin_setjmp/__builtin_longjmp and don't fall back to the libc
functions.
llvm-svn: 231245
|
| |
|
|
|
|
|
|
| |
This test doesn't provide any value (it just checks that the frontend
produces exactly one compile unit), and it certainly isn't doing what
the comment says. Noticed via IRC review of my update to it in r231083.
llvm-svn: 231152
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fsanitize=shift-exponent.
-fsanitize=shift is now a group that includes both these checks, so
exisiting users should not be affected.
This change introduces two new UBSan kinds that sanitize only left-hand
side and right-hand side of shift operation. In practice, invalid
exponent value (negative or too large) tends to cause more portability
problems, including inconsistencies between different compilers, crashes
and inadequeate results on non-x86 architectures etc. That is,
-fsanitize=shift-exponent failures should generally be addressed first.
As a bonus, this change simplifies CodeGen implementation for emitting left
shift (separate checks for base and exponent are now merged by the
existing generic logic in EmitCheck()), and LLVM IR for these checks
(the number of basic blocks is reduced).
llvm-svn: 231150
|
| |
|
|
|
|
|
| |
Update testcases for LLVM change in r231082 to use the new debug info
hierarchy.
llvm-svn: 231083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally we were using the same GCC builtins to lower this AVX2 vector
intrinsic. Instead we will now lower it directly to a vector shuffle.
This will not only allow LLVM to generate better code, but it will also allow us
to remove the GCC intrinsics.
Reviewed by Andrea
This is related to rdar://problem/18742778.
llvm-svn: 231081
|
| |
|
|
| |
llvm-svn: 230795
|
| |
|
|
| |
llvm-svn: 230783
|
| |
|
|
|
|
|
|
|
| |
The only change is that line 266 changed from
// CHECK: br label %[[except]]
to
// CHECK: br label %[[except:[^ ]*]]
llvm-svn: 230764
|
| |
|
|
|
|
|
| |
The tests keeps failing on build bots:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/2355/testReport/junit/Clang/CodeGen/exceptions_seh_leave_c/
llvm-svn: 230740
|
| |
|
|
|
|
| |
intrinsic headers.
llvm-svn: 230738
|
| |
|
|
|
|
|
|
|
|
| |
For global reg lvalue - use regular store through global register.
For simple lvalue - use simple atomic store.
For bitfields, vector element, extended vector elements - the original value of the whole storage (for vector elements) or of some aligned value (for bitfields) is atomically read, the part of this value for the given lvalue is modified and then use atomic compare-and-exchange operation to try to atomically write modified value (if it was not modified).
Also, changes in this patch fix the bug for '#pragma omp atomic read' applied to extended vector elements.
Differential Revision: http://reviews.llvm.org/D7369
llvm-svn: 230736
|
| |
|
|
| |
llvm-svn: 230720
|
| |
|
|
| |
llvm-svn: 230717
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The __finally emission block tries to be clever by removing unused continuation
edges if there's an unconditional jump out of the __finally block. With
exception edges, the EH continuation edge isn't always unused though and we'd
crash in a few places.
Just don't be clever. That makes the IR for __finally blocks a bit longer in
some cases (hence small and behavior-preserving changes to existing tests), but
it makes no difference in general and it fixes the last crash from PR22553.
http://reviews.llvm.org/D7918
llvm-svn: 230697
|
| |
|
|
|
|
|
|
|
|
|
| |
Currently, the NaN values emitted for MIPS architectures do not cover
non-IEEE754-2008 compliant case. This change fixes the issue.
Patch by Vladimir Radosavljevic.
Differential Revision: http://reviews.llvm.org/D7882
llvm-svn: 230653
|
| |
|
|
|
|
| |
headers. We use appropriate shuffle vector instead.
llvm-svn: 230616
|
| |
|
|
| |
llvm-svn: 230514
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original CL description:
Produce less broken basic block sequences for __finally blocks.
The way cleanups (such as PerformSEHFinally) get emitted is that codegen
generates some initialization code, then calls the cleanup's Emit() with the
insertion point set to a good place, then the cleanup is supposed to emit its
stuff, and then codegen might tack in a jump or similar to where the insertion
point is after the cleanup.
The PerformSEHFinally cleanup tries to just stash away the block it's supposed
to codegen into, and then does codegen later, into that stashed block. However,
after codegen'ing the __finally block, it used to set the insertion point to
the finally's continuation block (where the __finally cleanup goes when its body
is completed after regular, non-exceptional control flow). That's not correct,
as that block can (and generally does) already ends in a jump. Instead,
remember the insertion point that was current before the __finally got emitted,
and restore that.
Fixes two of the crashes in PR22553.
llvm-svn: 230503
|
| |
|
|
|
|
|
|
|
| |
The test is broken on buildbots:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/2279/
This reverts commit adda738b6dc533c42db5f5f5b31344098a3aba7d.
llvm-svn: 230472
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way cleanups (such as PerformSEHFinally) get emitted is that codegen
generates some initialization code, then calls the cleanup's Emit() with the
insertion point set to a good place, then the cleanup is supposed to emit its
stuff, and then codegen might tack in a jump or similar to where the insertion
point is after the cleanup.
The PerformSEHFinally cleanup tries to just stash away the block it's supposed
to codegen into, and then does codegen later, into that stashed block. However,
after codegen'ing the __finally block, it used to set the insertion point to
the finally's continuation block (where the __finally cleanup goes when its body
is completed after regular, non-exceptional control flow). That's not correct,
as that block can (and generally does) already ends in a jump. Instead,
remember the insertion point that was current before the __finally got emitted,
and restore that.
Fixes two of the crashes in PR22553.
llvm-svn: 230460
|
| |
|
|
| |
llvm-svn: 230454
|