ability to generate code that CodeGen likes. Test
cases can use this functionality by calling
// RUN: %clang_cc1 -emit-obj -o /dev/null -ast-merge %t.1.ast -ast-merge %t.2.ast %s
llvm-svn: 236011
We incorrectly replaced shadow slots
when the new value is not stronger than the old one.
The bug can lead to false negatives.
The bug was detected by Go race test suite:
https://github.com/golang/go/issues/10589
llvm-svn: 236008
Inclass initializer is instantiated in its own LocalInstantiationScope. It
causes problems when instantiating local classes - when instantiation scope
is searched for DeclContext of the field, the search fails. As a solution,
the instantiation scope of field initializer is combined with its outer
scope.
This patch fixes PR23194.
Differential Revision: http://reviews.llvm.org/D9258
llvm-svn: 236005
Fixes a crash with basically any OpenGL application using the radeonsi
driver.
Patch by: Michel Dänzer
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90176
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
llvm-svn: 236004
llc converts all feature strings to lower case, while the LLVM C API
does not, so we need a lower case alias in order to test this with llc.
llvm-svn: 236003
We need to track if an AddrSpaceCast expression was seen when
generating an MCExpr for a ConstantExpr. This change introduces a
custom lowerConstant method to the NVPTX asm printer that will create
NVPTXGenericMCSymbolRefExpr nodes at the appropriate places to encode
the information that a given symbol needs to be casted to a generic
address.
llvm-svn: 236000
This is a preliminary step to using the IR-level floating-point fast-math-flags in the SDAG (D8900).
In this patch, we introduce the optimization flags as their own struct. As noted in the TODO comment,
we should eventually share this data between the IR passes and the backend.
We also switch the existing nsw / nuw / exact bit functionality of the BinaryWithFlagsSDNode class to
use the new struct.
The tradeoff is that instead of using the free but limited space of SDNode's SubclassData, we add a
data member to the subclass. This means we don't have to repeat all of the get/set methods per flag,
but we're potentially adding size to all nodes of this subclassi type.
In practice on 64-bit systems (measured on Linux and MacOS X), there is no size difference between an
SDNode and BinaryWithFlagsSDNode after this change: they're both 80 bytes. This means that we had at
least one free byte to play with due to struct alignment.
Differential Revision: http://reviews.llvm.org/D9325
llvm-svn: 235997
During testing -data-list-register-values, I saw a crash here due to buffer overflow.
This commit should fix the crash. There is still problem with printing 1-byte register
in some cases that I will fix separately.
No regression on MI test cases.
llvm-svn: 235991
Summary: If the immediate is 0, the ORi is pointless.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8969
llvm-svn: 235990
[DebugInfo] Add debug locations to constant SD nodes
This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).
Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.
Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.
This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.
Differential Revision: http://reviews.llvm.org/D9084
llvm-svn: 235989
Summary: The new name is more accurate with regard to the functionality.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8968
llvm-svn: 235984
Summary: This removes multiple calls to getReg() and saves us column space in the source file.
Reviewers: dsanders
Reviewed By: dsanders
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8924
llvm-svn: 235978
This adds debug location to constant nodes of Selection DAG and updates
all places that create constants to pass debug locations
(see PR13269).
Can't guarantee that all locations are correct, but in a lot of cases choice
is obvious, so most of them should be. At least all tests pass.
Tests for these changes do not cover everything, instead just check it for
SDNodes, ARM and AArch64 where it's easy to get incorrect locations on
constants.
This is not complete fix as FastISel contains workaround for wrong debug
locations, which drops locations from instructions on processing constants,
but there isn't currently a way to use debug locations from constants there
as llvm::Constant doesn't cache it (yet). Although this is a bit different
issue, not directly related to these changes.
Differential Revision: http://reviews.llvm.org/D9084
llvm-svn: 235977
When creating a global variable with a type of a struct with bitfields, we must
forcibly set the alignment of the global from the RecordDecl. We must do this so
that the proper bitfield alignment makes its way down to LLVM, since clang will
mangle the bitfields into one large type.
llvm-svn: 235976
Summary:
When using GDB with MI, if there aren't children for a variable,
it doesn't include a "children" value in the response. LLDB does
and sets it to "[]" while variables with children have an unquoted
list: children=[...].
This removes the children value entirely when there are no children
making this match GDB in behavior.
Test Plan: Ran tests on Mac OS X and they passed.
Reviewers: abidh, domipheus
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9320
llvm-svn: 235974
Summary:
Without the synchronisation between the two thread creation events the following case could
happen:
- threads A and B are running. A hits a breakpoint. We note that we want to stop B.
- before we could stop it, B creates a new thread C, we get the stop notification for B, but we
don't record C's existence yet.
- we resume B
- before we get the C notification, B stops again (e.g. hits a breakpoint, gets our SIGSTOP,
etc.)
- we see all known threads have stopped, and we notify LLDB
- C notification comes, we note it's existence and resume it
=> we have an inconsistent state (LLDB thinks we've stopped, but C is running)
I resolve this by doing a blocking wait for for the C notification when we get the creation
notification on the parent (B) thread. This way the two events are synchronised, but we don't
need to introduce the intermediate "launching" state which would complicate handling of thread
states as all code would need to be aware of the third possible state.
Test Plan:
This is an obscure corner case, which I had not observed in practise, so I have no
test for it. I have tested that this commit does not regress in existing tests though.
Reviewers: chaoren, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9217
llvm-svn: 235969
As a space optimization, this instruction would just encode the pointer
type of the first operand and use the knowledge that the second and
third operands would be of the pointee type of the first. When typed
pointers go away, this assumption will no longer be available - so
encode the type of the second operand explicitly and rely on that for
the third.
Test case added to demonstrate the backwards compatibility concern,
which only comes up when the definition of the second operand comes
after the use (hence the weird basic block sequence) - at which point
the type needs to be explicitly encoded in the bitcode and the record
length changes to accommodate this.
llvm-svn: 235966
This papers over a layering violation currently between libc++abi and libunwind.
It reaches into the sources to get the declaration of an ABI defined function.
This should allow the ARM buildbot to continue building libc++abi again.
llvm-svn: 235965
Attempting to default the option to ON for ARM doesnt seem to work. Force the
check lower and perform the check at the two sites that matter: the CPPFLAGS
definition and the header search path setup.
llvm-svn: 235964
This matches other assemblers and is less unexpected (e.g. PR23227).
On ELF, I tried binutils gas v2.24 and nasm 2.10.09, and they both
agree on LShr. On COFF, I couldn't get my hands on an assembler yet,
so don't change the behavior. For now, don't change it on non-AArch64
Darwin either, as the other assembler is gas v1.38, which does an AShr.
llvm-svn: 235963
Sean Callanan