llvm-svn: 295459

This case should be possible to handle, but it is hard:

* In order to create program headers correctly, we have to scan the
  sections in the order they are in the file.

* To find that order, we have to "execute" the linker script.

* The linker script can contain SIZEOF_HEADERS.

So to support this we have to start with a guess of how many headers
we need (3), run the linker script and try to create the program
headers. If it turns out we need more headers, we run the script again
with a larger SIZEOF_HEADERS.

Also, running the linker script depends on knowing the size of the
sections, so we have to finalize them. But creating the program
headers can change the value stored in some sections, so we have to
split size finalization and content finalization.

Looks like the last part is also needed for range extension thunks, so
we might support this at some point. For now just report an error
instead of producing broken files.

llvm-svn: 295458

llvm-svn: 295457

We previously only created a vector phi node for an induction variable if its
step had a constant integer type. However, the step actually only needs to be
loop-invariant. We only handle inductions having loop-invariant steps, so this
patch should enable vector phi node creation for all integer induction
variables that will be vectorized.

Differential Revision: https://reviews.llvm.org/D29956

llvm-svn: 295456

llvm-svn: 295455

We were only checking when the assignment was inside a section.

llvm-svn: 295454

llvm-svn: 295453

Removed the HasT2ExtractPack feature and replaced its references
with HasDSP. This then allows the Thumb2 extend instructions to be
selected for ARMv8M +dsp. These instruction descriptions have also
been refactored and more target tests have been added for their isel.

Differential Revision: https://reviews.llvm.org/D29623

llvm-svn: 295452

During legalization we are often creating shuffles (via a build_vector scalarization stage) that are "any_extend_vector_inreg" style masks, and also other masks that are the equivalent of "truncate_vector_inreg" (if we had such a thing).

This patch is an attempt to match these cases to help undo the effects of just leaving shuffle lowering to handle it - which typically means we lose track of the undefined elements of the shuffles resulting in an unnecessary extension+truncation stage for widened illegal types.

The 2011-10-21-widen-cmp.ll regression will be fixed by making SIGN_EXTEND_VECTOR_IN_REG legal in SSE instead of lowering them to X86ISD::VSEXT (PR31712).

Differential Revision: https://reviews.llvm.org/D29454

llvm-svn: 295451

llvm-svn: 295450

This caused a failure in Linux-x86_64 stack-use-after-return

This reverts commit 1f9563141e999016d13ac3fc6a50fde690381e82.

llvm-svn: 295449

llvm-svn: 295448

llvm-svn: 295447

Return invalid opcodes when some of the helpers in the instruction selection
pass can't handle a given combination.

llvm-svn: 295446

Summary:
There have been a few new values added to a few LLVM enums
this change makes sure that LLDB code handles them correctly.

Reviewers: labath

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D30005
Author: Eugene Zemtsov <ezemtsov@google.com>

llvm-svn: 295445

llvm-svn: 295444

The way of injecting an error into the printf call was not working on
darwin - the C library still happily format the character. It only
returns an error after we use a wide character that does not fit into a
single byte, so switch the test to use that.

llvm-svn: 295443

Changes wrt. previous version:
- add #include <atomic>: fix build on windows
- add extra {} around the string literals used to initialize
  llvm::StringLiteral: fix gcc build

llvm-svn: 295442

Add some asserts to make sure we're using the mappings that we think we're
using. This is to keep us from accidentally breaking functionality while moving
to TableGen'erated mappings.

llvm-svn: 295441

In the case we are stepping over the thread creation instruction, we
will end up calling Thread::SingleStep back-to-back twice (because of
the intermediate PTRACE_EVENT_CLONE stop). This will cause the cpu mask
to be set inappropriately (because the old SingleStepCheck object will
be destroyed after we create the new one), and the single-step will
fail.

Before the refactor the code was still incorrect in this case, but in a
different way (the thread was left with the incorrect mask after the
stepping was complete), so this was not easy to spot.

This fixes TestCreateDuringInstructionStep on the affected devices.

llvm-svn: 295440

Start using the Subtarget to make decisions about what's legal. In particular,
we only mark floating point operations as legal if we have VFP2, which is
something we should've done from the very start.

llvm-svn: 295439

Test some really basic functionality through the whole GlobalISel pipeline.

llvm-svn: 295438

This can lead to bad behavior with macros that are used to annotate
functions (e.g. ALWAYS_INLINE).

Before, this:
  ALWAYS_INLINE ::std::string getName() ...

was turned into:
  ALWAYS_INLINE::std::string getName() ...

If it turns out that clang-format is failing to clean up a lot of the
existing spaces now, we can add more analyses of the identifier. It
should not currently. Cases where clang-format breaks nested name
specifiers should be fine as clang-format wraps after the "::". Thus, a
line getting longer and then shorter again should lead to the same
original code.

llvm-svn: 295437

Also move the ErrorTest into the Utility package, to follow the class it
is testing.

llvm-svn: 295436

Differential Revision: https://reviews.llvm.org/D23421

llvm-svn: 295435

llvm-svn: 295434

llvm-svn: 295433

llvm-svn: 295432

llvm-svn: 295431

Before this change, we obtained loop depth numbers that were deeper then the
actual loop depth.

llvm-svn: 295430

Differential revision: https://reviews.llvm.org/D29491

llvm-svn: 295429

GCC 7.0.1 started warning that __attribute__((__strong__)) is depricated.
This patch switches to using inline namespace with GCC instead. I believe
this wasn't done originally in order to support older GCC versions w/o
support for inline namespaces, or because earlier versions of GCC warned
users that the STL was using an inline namespace (even though it shouldn't affect users).

However I believe all of the above problems are gone for GCC 4.9 and greater.
Therefore switching to using inline namespaces instead of using __strong__
is the most correct behavior.

llvm-svn: 295428

llvm-svn: 295427

llvm-svn: 295426

[IR][X86] Rename an AutoUpgrade helper function to more accurately match what intrinsics it handles. NFC

llvm-svn: 295425

This enables some early outs to avoid repeatedly using IsX86 check to qualify. I hope to continue to improve this to shorten the lengths of some of the string comparisons.

llvm-svn: 295424

llvm-svn: 295423

llvm-svn: 295422

A slightly weaker form of ODR checking than previous attempts, but hopefully
won't break the modules build bot.  Future work will be needed to catch all
cases.

When objects are imported for modules, there is a chance that a name collision
will cause an ODR violation.  Previously, only a small number of such
violations were detected.  This patch provides a stronger check based on
AST nodes.

The information needed to uniquely identify an object is taken from the AST and
put into a one-dimensional byte stream.  This stream is then hashed to give
a value to represent the object, which is stored with the other object data
in the module.

When modules are loaded, and Decl's are merged, the hash values of the two
Decl's are compared.  Only Decl's with matched hash values will be merged.
Mismatch hashes will generate a module error, and if possible, point to the
first difference between the two objects.

The transform from AST to byte stream is a modified depth first algorithm.
Due to references between some AST nodes, a pure depth first algorithm could
generate loops.  For Stmt nodes, a straight depth first processing occurs.
For Type and Decl nodes, they are replaced with an index number and only on
first visit will these nodes be processed.  As an optimization, boolean
values are saved and stored together in reverse order at the end of the
byte stream to lower the ammount of data that needs to be hashed.

Compile time impact was measured at 1.5-2.0% during module building, and
negligible during builds without module building.

Differential Revision: https://reviews.llvm.org/D21675

llvm-svn: 295421

Patch by Ryuichi Hayashida!

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

llvm-svn: 295420