Emit and use the TableGen instruction selector for ARM. At the moment,
this allows us to remove the hand-written code for selecting G_SDIV and
G_UDIV.

Future commits will focus on increasing the code coverage for it and
removing more dead code from the current instruction selector.

llvm-svn: 301905

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

llvm-svn: 301904

Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.

Reviewers: #lldb, zturner

Reviewed By: zturner

Subscribers: zturner, tberghammer, jingham, lldb-commits

Differential Revision: https://reviews.llvm.org/D32503
Patch by Scott Smith <scott.smith@purestorage.com>.

llvm-svn: 301903

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

llvm-svn: 301902

I think this method is probably too complex to be inlined.

llvm-svn: 301901

This makes setBit/clearBit more consistent with setBits which is already inlined.

llvm-svn: 301900

Makes code more readable. The function will also be used
by the partial inlining's cost analysis.

llvm-svn: 301899

MicrosoftRecordLayoutBuilder doesn't have ability of -Wpadded.

FIXME: Would other diag be available here?
llvm-svn: 301898

If there is a bug in the LTO implementation that causes it to fail to provide
an expected symbol definition, the linker should report an undefined symbol
error. Unfortunately, we were failing to do so if the symbol definition
was weak, as the undefine() function was turning the definition into a weak
undefined symbol, which resolves to zero if the symbol remains undefined. This
patch causes us to set the binding to STB_GLOBAL when we undefine a symbol.

I can't see a good way to test this. The behaviour should only be observable
if there is a bug in the LTO implementation.

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

llvm-svn: 301897

llvm-svn: 301896

It didn't have to be a member function of Driver. This patch makes
that function a file-scoped non-member function.

llvm-svn: 301895

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

llvm-svn: 301894

A recent commit I made made it so that we only did this for signal or
interrupt handlers. This broke normal functions.

llvm-svn: 301893

Fixes PR30730.
This is a re-commit of a pulled commit. The commit was pulled because some
software projects contained uses of Altivec vectors that violated alignment
requirements. Known issues have now been fixed.

Committing on behalf of Lei Huang.

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

llvm-svn: 301892

The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent exprs instead of exprs with one element. Fixing that uncovers one testcase failure because the AST for "constexpr _Complex float test2 = {1};" is wrong (the _Complex prvalue should not be const-qualified), and a number of test failures in test/OpenMP where the captured stmt contains an InitListExpr that is in syntactic form.

llvm-svn: 301891

r288279 mistakenly added it to all arches, but it's only available
from v8.1 onwards.

The testcase is awkward, because (I suspect) of PR32873.

Spotted by inspection.

llvm-svn: 301890

llvm-svn: 301889

llvm-svn: 301888

Because it was a callee-saved register, we automatically generated code
to spill and unspill its original value so that it is restored after the
function returns.

The problem is that this code was being generated before the epilogue.
The epilogue itself uses the Y register, which could be prematurely
restored by the CSR restoration process.

This removes R29R28 from the CSR list and changes the prologue/epilogue
code to handle it explicitly.

llvm-svn: 301887

This change caused buildbot failures, apparently because we're not
passing around types that InstSimplify is used to seeing. I'm not overly
familiar with InstSimplify, so I'm reverting this until I can figure out
what exactly is wrong.

llvm-svn: 301885

Rename parameters and locals to CamelCase, doxygenize the header, and
run clang-format on the whole thing.

llvm-svn: 301883

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

llvm-svn: 301882

This is a temporary measure while we figure out a way to get the frame
pointer working correctly.

llvm-svn: 301881

In particular (since it wouldn't fit nicely in the summary):
(select (icmp eq V 0) P (getelementptr P V)) -> (getelementptr P V)

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

llvm-svn: 301880

[X86] Reduce code for setting operations actions by merging into loops across multiple types/ops. NFCI.

llvm-svn: 301879

llvm-svn: 301878

llvm-svn: 301877

llvm-svn: 301852

This tracks whether MaxCallFrameSize is computed yet. Ideally we would
assert and fail when the value is queried before it is computed, however
this fails various targets that need to be fixed first.

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

llvm-svn: 301851

llvm-svn: 301850

In the testcase attached,  we believe %tmp1 implies %tmp4.
where:
  br i1 %tmp1, label %bb2, label %bb7
  br i1 %tmp4, label %bb5, label %bb7

because Wwhile looking at PredicateInfo stuffs we end up calling
isImpliedTrueByMatchingCmp() with the arguments backwards.

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

llvm-svn: 301849

If we have ~(~X & Y), it only makes sense to transform it to (X | ~Y) when we do not need 
the intermediate (~X & Y) value. In that case, we would need an extra instruction to 
generate ~Y + 'or' (as shown in the test changes).

It's ok if we have multiple uses of ~X or Y, however. In those cases, we may not reduce the
instruction count or critical path, but we might improve throughput because we can generate 
~X and ~Y in parallel. Whether that actually makes perf sense or not for a target is something 
we can't answer in IR.

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

llvm-svn: 301848

llvm-svn: 301847

If a file has no diagnostic pragmas, we build its diagnostic state lazily, but
in this case we never set up the root state to be the diagnostic state in which
the module was originally built, so the diagnostic flags for files in the
module with no diagnostic pragmas were incorrectly based on the user of the
module rather than the diagnostic state when the module was built.

llvm-svn: 301846

llvm-svn: 301845

lldb-dwarfdump gets a new "--verify" option that will verify a single file's DWARF debug info and will print out any errors that it finds. It will return an non-zero exit status if verification fails, and a zero exit status if verification succeeds. Adding the --quiet option will suppress any output the STDOUT or STDERR.

The first part of the verify does the following:

- verifies that all CU relative references (DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref8, DW_FORM_ref_udata) have valid CU offsets
- verifies that all DW_FORM_ref_addr references have valid .debug_info offsets
- verifies that all DW_AT_ranges attributes have valid .debug_ranges offsets
- verifies that all DW_AT_stmt_list attributes have valid .debug_line offsets
- verifies that all DW_FORM_strp attributes have valid .debug_str offsets

Unit tests were added for each of the above cases.

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

llvm-svn: 301844

This is to prepare for an upcoming change which uses pointers instead of
GUIDs to represent references.

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

llvm-svn: 301843

[APInt] In operator!, handle single word case by comparing VAL to 0 directly and handle multiword case by comparing countLeadingZerosSlowCase() to BitWidth.

We were using operator=(0) which implicitly calls countLeadingZeros but only to compare with 64 to determine if we can compare VAL or pVal[0] to uint64_t. By handling the multiword case with countLeadingZerosSlowCase==BitWidth we can prevent a load of pVal[0] from being inserted inline at each call site. This saves a little bit of code size.

llvm-svn: 301842

NFC

llvm-svn: 301841

These tests do not appear to be Darwin-specific, and this REQUIRES: appears to
be hiding a real bug; this change is just restoring the prior state to get the
buildbots happy again while we investigate. (The system-darwin requirement is
covered by PR32851.)

llvm-svn: 301840