Commit Graph

599 Commits

Author SHA1 Message Date
David Blaikie 43f9bb7371 API update for streamlining of IRBuilder::CreateCall to just use ArrayRef/initializer_list+braced init
llvm-svn: 237625
2015-05-18 22:14:03 +00:00
Peter Collingbourne 3eea677f3a Unify sanitizer kind representation between the driver and the rest of the compiler.
No functional change.

Differential Revision: http://reviews.llvm.org/D9618

llvm-svn: 237055
2015-05-11 21:39:14 +00:00
Justin Bogner 66242d6c5e InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)
The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.

llvm-svn: 235664
2015-04-23 23:06:47 +00:00
Alexey Samsonov f624650354 Unify the way we report overflow in increment/decrement operator.
Summary:
Make sure signed overflow in "x--" is checked with
llvm.ssub.with.overflow intrinsic and is reported as:
  "-2147483648 - 1 cannot be represented in type 'int'"
instead of:
  "-2147483648 + -1 cannot be represented in type 'int'"
, like we do for unsigned overflow.

Test Plan: clang + compiler-rt regression test suite

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D8236

llvm-svn: 235568
2015-04-23 01:50:45 +00:00
David Blaikie 1ed728c499 [opaque pointer type] More GEP API migrations
Looks like the VTable code in particular will need some work to pass
around the pointee type explicitly.

llvm-svn: 234128
2015-04-05 22:45:47 +00:00
Alexey Bataev b4505a7229 [OPENMP] Codegen for 'atomic update' construct.
Adds atomic update codegen for the following forms of expressions:

x binop= expr;
x++;
++x;
x--;
--x;
x = x binop expr;
x = expr binop x;
If x and expr are integer and binop is associative or x is a LHS in a RHS of the assignment expression, and atomics are allowed for type of x on the target platform atomicrmw instruction is emitted.
Otherwise compare-and-swap sequence is emitted:

bb:
...
atomic load <x>
cont:
<expected> = phi [ <x>, label %bb ], [ <new_failed>, %cont ]
<desired> = <expected> binop <expr>
<res> = cmpxchg atomic &<x>, desired, expected
<new_failed> = <res>.field1;
br <res>field2, label %exit, label %cont
exit:
...

Differential Revision: http://reviews.llvm.org/D8536

llvm-svn: 233513
2015-03-30 05:20:59 +00:00
Ahmed Bougacha 6ba3831ebe [CodeGen] Support native half inc/dec amounts.
We previously defaulted to long double, but it's also possible to have
a half inc/dec amount, when LangOpts NativeHalfType is set.
Currently, that's only true for OpenCL.

llvm-svn: 233135
2015-03-24 23:44:42 +00:00
Ahmed Bougacha d1801afeac [CodeGen] Properly support the half FP type with non-native operations.
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
2015-03-23 17:54:16 +00:00
Ahmed Bougacha 47ec2c7479 [CodeGen] Convert double -> __fp16 in one step.
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
2015-03-23 17:48:07 +00:00
Peter Collingbourne d2926c91d5 Implement bad cast checks using control flow integrity information.
This scheme checks that pointer and lvalue casts are made to an object of
the correct dynamic type; that is, the dynamic type of the object must be
a derived class of the pointee type of the cast. The checks are currently
only introduced where the class being casted to is a polymorphic class.

Differential Revision: http://reviews.llvm.org/D8312

llvm-svn: 232241
2015-03-14 02:42:25 +00:00
Alexey Samsonov 21d2dda3d2 [UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -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
2015-03-09 21:50:19 +00:00
Alexey Samsonov 48a9db034a Revert "[UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -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
2015-03-05 21:57:35 +00:00
Alexey Samsonov 783b8174ad [UBSan] Split -fsanitize=shift into -fsanitize=shift-base and -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
2015-03-03 22:15:35 +00:00
David Majnemer ced8bdf74a Sema: Parenthesized bound destructor member expressions can be called
We would wrongfully reject (a.~A)() in both the destructor and
pseudo-destructor cases.

This fixes PR22668.

llvm-svn: 230512
2015-02-25 17:36:15 +00:00
Richard Smith 527473df0d Fix typoo.
llvm-svn: 228963
2015-02-12 21:23:20 +00:00
David Blaikie 38b2591469 DebugInfo: Refactor default arg handling into a common place (instead of handling in repeatedly for aggregate, complex, and scalar types)
llvm-svn: 228591
2015-02-09 19:13:51 +00:00
David Blaikie 14177b748a DebugInfo: Ensure calls to functions with default arguments which themselves have default arguments, still have locations.
To handle default arguments in C++ in the debug info, we disable code
updating the debug location during the emission of default arguments.

This code was buggy in the case of default arguments which, themselves,
have default arguments - the inner default argument would re-enable
debug info when it was finished, but before the outer default argument
was finished.

This was already a bug, but got worse (because a crasher instead of just
a quality bug) with the recent improvements to debug info line quality
because... The ApplyDebugLocation scoped device would find the debug
info disabled and not save any debug location. But then in
~ApplyDebugLocation it would find the debug info had been enabled and
would then apply the no-location. Then the outer function call would be
emitted without any location. That's bad.

Arguably we could /also/ fix the ApplyDebugLocation to assert on this
situation (where debug info was disabled in the ctor and enabled in the
dtor, or the other way around) but this is at least the necessary fix
regardless.

(also, I imagine this disabling behavior might need to be in-place for
CGExprComplex and CGExprAgg too, maybe... ?)

And I seem to recall seeing some weird default arg stepping behavior
recently which might be related to this too... I'll have to look into
it.

llvm-svn: 228053
2015-02-03 22:37:17 +00:00
Adrian Prantl 95b24e9b59 Address review feedback for r228003.
- use named constructors
- get rid of MarkAsPrologue

llvm-svn: 228021
2015-02-03 20:00:54 +00:00
Adrian Prantl 39428e74a0 Merge ArtificialLocation into ApplyDebugLocation and make a clear
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.

Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.

rdar://problem/19670595

llvm-svn: 228003
2015-02-03 18:40:42 +00:00
David Blaikie 9b47966615 DebugInfo: Use the preferred location rather than the start location for expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.

There were essentially 3 options for this:

* The beginning of an expression (this was the behavior prior to this
  commit). This meant that stepping through subexpressions would bounce
  around from subexpressions back to the start of the outer expression,
  etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
  where the actual addition occurred)).

* The end of an expression. This seems to be what GCC does /mostly/, and
  certainly this for function calls. This has the advantage that
  progress is always 'forwards' (never jumping backwards - except for
  independent subexpressions if they're evaluated in interesting orders,
  etc). "x + y + z" would go "x y z" with the additions occurring at y
  and z after the respective loads.
  The problem with this is that the user would still have to think
  fairly hard about precedence to realize which subexpression is being
  evaluated or which operator overload is being called in, say, an asan
  backtrace.

* The preferred location or 'exprloc'. In this case you get sort of what
  you'd expect, though it's a bit confusing in its own way due to going
  'backwards'. In this case the locations would be: "x y + z +" in
  lovely postfix arithmetic order. But this does mean that if the op+
  were an operator overload, say, and in a backtrace, the backtrace will
  point to the exact '+' that's being called, not to the end of one of
  its operands.

(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)

llvm-svn: 227027
2015-01-25 01:19:10 +00:00
David Blaikie 66e4197f07 Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).
Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225956
2015-01-14 07:38:27 +00:00
Daniel Sanders cdcb580d4e [mips] Fix va_arg() for pointer types on big-endian N32.
Summary:
The Mips ABI's treat pointers in the same way as integers. They are
sign-extended to 32-bit for O32, and 64-bit for N32/N64. This doesn't matter
for O32 and N64 where pointers are already the correct width but it does matter
for big-endian N32, where pointers are 32-bit and need promoting.

The caller side is already passing pointers correctly. This patch corrects the
callee.

Reviewers: vmedic, atanasyan

Reviewed By: atanasyan

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6812

llvm-svn: 225782
2015-01-13 10:47:00 +00:00
David Blaikie f353d3ecd0 Revert "DebugInfo: Generalize debug info location handling" and related commits
This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.

I'll work up some test cases and fixes before recommitting this.

llvm-svn: 225555
2015-01-09 23:00:28 +00:00
David Blaikie 84fe79cfc3 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225000
2014-12-30 19:39:33 +00:00
David Blaikie 608a24501c Revert "DebugInfo: Generalize debug info location handling"
Asserting when building compiler-rt when using a GCC host compiler.
Reverting while I investigate.

This reverts commit r224941.

llvm-svn: 224970
2014-12-29 23:49:00 +00:00
David Blaikie 3945d1bd99 Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224941
2014-12-29 18:18:45 +00:00
Pekka Jaaskelainen e94b0e1870 Fix an address space id reset with array decay's
implicit conversion. 

The issue was produced with OpenCL C code that 
called a function with a constant string literal
argument.

llvm-svn: 224592
2014-12-19 18:04:27 +00:00
David Blaikie 06b2c54db9 Revert "DebugInfo: Generalize debug info location handling"
Fails an ASan bootstrap - I'll try to reproduce locally & sort that out
before recommitting.

This reverts commit r224385.

llvm-svn: 224441
2014-12-17 18:02:04 +00:00
David Blaikie bf22a4eaee DebugInfo: Generalize debug info location handling
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 224385
2014-12-16 22:49:17 +00:00
Alexey Bataev 452d8e1133 Bugfix for Codegen of atomic load/store/other ops.
Currently clang fires assertions on x86-64 on any atomic operations for long double operands. Patch fixes codegen for such operations.
Differential Revision: http://reviews.llvm.org/D6499

llvm-svn: 224230
2014-12-15 05:25:25 +00:00
David Majnemer 17e2633cd6 CodeGen: Compound literals with funny types shouldn't crash
CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.

We had two bugs in this area:
- Zero sized arrays in compound literals would lead to the creation of
  an opaque type.  This is unnecessary, we should just create an array
  type with a bound of zero.
- Funny record types (like unions) lead to exotic IR types for compound
  literals.  In this case, CodeGen must be prepared to deal with the
  possibility that it might not have an array IR type.

This fixes PR21912.

llvm-svn: 224219
2014-12-14 12:16:43 +00:00
Anastasia Stulova 5d8ad8a7b8 [OpenCL] Implemented restrictions for pointer conversions specified in OpenCL v2.0.
OpenCL v2.0 s6.5.5 restricts conversion of pointers to different address spaces:
- the named address spaces (__global, __local, and __private) => __generic - implicitly converted;
- __generic => named - with an explicit cast;
- named <=> named - disallowed;
- __constant <=> any other - disallowed.

llvm-svn: 222834
2014-11-26 15:36:41 +00:00
Daniel Sanders 59229dcb29 Allow EmitVAArg() to promote types and use this to fix some N32/N64 vararg issues for Mips.
Summary:
With this patch, passing a va_list to another function and reading 10 int's from
it works correctly on a big-endian target.

Based on a pair of patches by David Chisnall, one of which I've reworked
for the current trunk.

Reviewers: theraven, atanasyan

Reviewed By: theraven, atanasyan

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6248

llvm-svn: 222339
2014-11-19 10:01:35 +00:00
Alexey Samsonov e396bfc064 Bundle conditions checked by UBSan with sanitizer kinds they implement.
Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to be true),
together with sanitizer kinds these checks are for. This would allow
to split one call into UBSan runtime into several calls in case
different sanitizer kinds would have different recoverability
settings.

Tests should be fixed accordingly, I'm working on it.

Test Plan: regression test suite.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6219

llvm-svn: 221716
2014-11-11 22:03:54 +00:00
Alexey Samsonov 4c1a96f519 Propagate SanitizerKind into CodeGenFunction::EmitCheck() call.
Make sure CodeGenFunction::EmitCheck() knows which sanitizer
it emits check for. Make CheckRecoverableKind enum an
implementation detail and move it away from header.

Currently CheckRecoverableKind is determined by the type of
sanitizer ("unreachable" and "return" are unrecoverable,
"vptr" is always-recoverable, all the rest are recoverable).
This will change in future if we allow to specify which sanitizers
are recoverable, and which are not by -fsanitize-recover= flag.

No functionality change.

llvm-svn: 221635
2014-11-10 22:27:30 +00:00
Alexey Samsonov edf99a92c0 Introduce a SanitizerKind enum to LangOptions.
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.

No functionality change.

llvm-svn: 221558
2014-11-07 22:29:38 +00:00
Alexey Samsonov 035462c1cf Get rid of SanitizerOptions::Disabled global. NFC.
SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
method, and let each CodeGenFunction has its own copy of SanitizerOptions
it uses.

llvm-svn: 220920
2014-10-30 19:33:44 +00:00
Alexey Samsonov eb47d8a2c8 Sanitize upcasts and conversion to virtual base.
This change adds UBSan check to upcasts. Namely, when we
perform derived-to-base conversion, we:
1) check that the pointer-to-derived has suitable alignment
   and underlying storage, if this pointer is non-null.
2) if vptr-sanitizer is enabled, and we perform conversion to
   virtual base, we check that pointer-to-derived has a matching vptr.

llvm-svn: 219642
2014-10-13 23:59:00 +00:00
Chandler Carruth 60fdc41346 Suppress a warning about an unused variable in NDEBUG builds.
llvm-svn: 219571
2014-10-11 11:29:26 +00:00
Chandler Carruth b29a743891 [complex] Teach the other two binary operators on complex numbers (==
and !=) to support mixed complex and real operand types.

This requires removing an assert from SemaChecking, and adding support
both to the constant evaluator and the code generator to synthesize the
imaginary part when needed. This seemed somewhat cleaner than having
just the comparison operators force real-to-complex conversions.

I've added test cases for these operations. I'm really terrified that
there were *no* tests in-tree which exercised this.

This turned up when trying to build R after my change to the complex
type lowering.

llvm-svn: 219570
2014-10-11 11:03:30 +00:00
Hal Finkel 64567a80d2 Emit @llvm.assume for non-parameter lvalue align_value-attribute loads
We already add the align parameter attribute for function parameters that have
the align_value attribute (or those with a typedef type having that attribute),
which is an important special case, but does not handle pointers with value
alignment assumptions that come into scope in any other way. To handle the
general case, emit an @llvm.assume-based alignment assumption whenever we load
the pointer-typed lvalue of an align_value-attributed variable (except for
function parameters, which we already deal with at entry).

I'll also note that this is more general than Intel's described support in:
  https://software.intel.com/en-us/articles/data-alignment-to-assist-vectorization
which states that the compiler inserts __assume_aligned directives in response
to align_value-attributed variables only for function parameters and for the
initializers of local variables. I think that we can make the optimizer deal
with this more-general scheme (which could lead to a lot of calls to
@llvm.assume inside of loop bodies, for example), but if not, I'll rework this
to be less aggressive.

llvm-svn: 219052
2014-10-04 15:26:49 +00:00
David Blaikie 66088d5917 Include debug info for types referenced only via explicit cast expressions.
Most of the debug info emission is powered essentially from function
definitions - if we emit the definition of a function, we emit the types
of its parameters, the members of those types, and so on and so forth.

For types that aren't referenced even indirectly due to this - because
they only appear in temporary expressions, not in any named variable, we
need to explicitly emit/add them as is done here. This is not the only
case of such code, and we might want to consider handling "void
func(void*); ... func(new T());" (currently debug info for T is not
emitted) at some point, though GCC doesn't. There's a much broader
solution to these issues, but it's a lot of work for possibly marginal
gain (but might help us improve the default -fno-standalone-debug
behavior to be even more aggressive in some places). See the original
review thread for more details.

Patch by jyoti allur (jyoti.yalamanchili@gmail.com)!

Differential Revision: http://reviews.llvm.org/D2498

llvm-svn: 218390
2014-09-24 17:01:27 +00:00
Oliver Stannard ed8ecc8429 Allow __fp16 as a function arg or return type for AArch64
ACLE 2.0 allows __fp16 to be used as a function argument or return
type. This enables this for AArch64.

This also fixes an existing bug that causes clang to not allow
homogeneous floating-point aggregates with a base type of __fp16. This
is valid for AAPCS64, but not for AAPCS-VFP.

llvm-svn: 216558
2014-08-27 16:31:57 +00:00
Alexey Samsonov 24cad99307 [UBSan] Add !nosanitize metadata to the code generated by UBSan.
This is used to mark the instructions emitted by Clang to implement
variety of UBSan checks. Generally, we don't want to instrument these
instructions with another sanitizers (like ASan).

Reviewed in http://reviews.llvm.org/D4544

llvm-svn: 213291
2014-07-17 18:46:27 +00:00
Tim Northover 6dbcbac98b IR: update Clang to use polymorphic __fp16 conversion intrinsics.
There should be no change in semantics at this stage.

llvm-svn: 213249
2014-07-17 10:51:31 +00:00
David Blaikie 1b5adb82d9 Fix the dtor location issues in PR20038 harder.
Originally committed in r211722, this fixed one case of dtor calls being
emitted without locations (this causes problems for debug info if the
call is then inlined), this caught only some of the cases.

Instead of trying to re-enable the location before the cleanup, simply
re-enable the location immediately after the unconditional branches in
question using a scoped device to ensure the no-location state doesn't
leak out arbitrarily.

llvm-svn: 212761
2014-07-10 20:42:59 +00:00
Alexey Samsonov ac4afe49e7 [Sanitizer] Remove brittle cache variable and slightly simplify blacklisting code.
Now CodeGenFunction is responsible for looking at sanitizer blacklist
(in CodeGenFunction::StartFunction) and turning off instrumentation,
if necessary.

No functionality change.

llvm-svn: 212501
2014-07-07 23:59:57 +00:00
Richard Smith 45d099b995 Cleanup. No functionality change intended.
llvm-svn: 212432
2014-07-07 05:36:14 +00:00
David Blaikie 21cd7cfd01 PR20038: DebugInfo: Call sites without DebugLocs for temporary dtors after a conditional
With && at the top level of an expression, the last thing done when
emitting the expression was an unconditional jump to the cleanup block.
To reduce the amount of stepping, the DebugLoc is omitted from the
unconditional jump. This is done by clearing the IRBuilder's
"CurrentDebugLocation"*. If this is not set to some non-empty value
before the cleanup block is emitted, the cleanups don't get a location
either. If a call without a location is emitted in a function with debug
info, and that call is then inlined - bad things happen. (without a
location for the call site, the inliner would just leave the inlined
DebugLocs as they were - pointing to roots in the original function, not
inlined into the current function)

Follow up commit to LLVM will ensure that breaking the invariants of the
DebugLoc chains by having chains that don't lead to the current function
will fail assertions, so we shouldn't accidentally slip any of these
cases in anymore. Those assertions may reveal further cases that need to
be fixed in clang, though I've tried to test heavily to avoid that.

* See r128471, r128513 for the code that clears the
  CurrentDebugLocation. Simply removing this code or moving the code
  into IRBuilder to apply to all unconditional branches would regress
  desired behavior, unfortunately.

llvm-svn: 211722
2014-06-25 17:57:34 +00:00
Tim Northover b49b04bbe0 IR-change: cmpxchg operations now return { iN, i1 }.
This is a minimal fix for clang. I'll soon add support for generating
weak variants when requested, but that's not really necessary for the
LLVM change in isolation.

llvm-svn: 210907
2014-06-13 14:24:59 +00:00