It's not possible to get the fragment size of some dbg.values. Teach the
mis-sized dbg.value diagnostic to detect this scenario and bail out.

Tested with:
$ find test/Transforms -print -exec opt -debugify-each -instcombine {} \;

llvm-svn: 335695

Nothing was using this relationship. By splitting them we no longer need to worry about register or memory entries being empty in a group.

The memory folding tables in X86InstrInfo.cpp can be used to access this relationship if needed.

llvm-svn: 335694

The android sanitizer bot can't resolve the function name in the DSO and
it's not relevant to the test.

llvm-svn: 335693

FreeBSD's mips64 builds O32 binaries for /usr/lib32 by default and
thus needs to be able to link O32 binaries which requires an explicit
linker emulation.  Go ahead and list all the linker emulation variants
for MIPS so that any supported MIPS ABI binary can be linked by any
linker supporting MIPS.

Reviewed By: atanasyan

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

llvm-svn: 335691

llvm-svn: 335690

Fix that to _wp.

llvm-svn: 335689

llvm-svn: 335688

We track when we see a name-shaped expression followed by a '<' token
and parse the '<' as a comparison. Then:

 * if we see a token sequence that cannot possibly be an expression but
   can be a template argument (in particular, a type-id) that follows
   either a ',' or the '<', diagnose that the '<' was supposed to start
   a template argument list, and
 * if we see '>()', diagnose that the '<' was supposed to start a
   template argument list.

This only changes the diagnostic for error cases, and in practice
appears to catch the most common cases where a missing 'template'
keyword leads to parse errors within a template.

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

llvm-svn: 335687

r335618 added tests that invoke llvm-as, so we should also ensure that
running clang tests rebuilds llvm-as.

llvm-svn: 335686

llvm-svn: 335685

Depends on r334313, which has been reverted in r335681.

llvm-svn: 335684

llvm-svn: 335683

Report an error in -check-debugify when the size of a dbg.value operand
doesn't match up with the size of the variable it describes.

Eventually this check should be moved into the IR verifier. For the
moment, it's useful to include the check in -check-debugify as a means
of catching regressions and finding existing bugs.

Here are some instances of bugs the new check finds in the -O2 pipeline
(all in InstCombine):

1) A float is used where a double is expected:

ERROR: dbg.value operand has size 32, but its variable has size 64:
call void @llvm.dbg.value(metadata float %expf, metadata !12, metadata
!DIExpression()), !dbg !15

2) An i8 is used where an i32 is expected:

ERROR: dbg.value operand has size 8, but its variable has size 32:
call void @llvm.dbg.value(metadata i8 %t4, metadata !14, metadata
!DIExpression()), !dbg !24

3) A <4 x i32> is used where something twice as large is expected
(perhaps a <4 x i64>, I haven't double-checked):

ERROR: dbg.value operand has size 128, but its variable has size 256:
call void @llvm.dbg.value(metadata <4 x i32> %4, metadata !40, metadata
!DIExpression()), !dbg !95

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

llvm-svn: 335682

Causes false positive ODR violation reports on __llvm_profile_raw_version.

llvm-svn: 335681

This should fix the recent builder failures in the test-global-ctors.ll testcase.

llvm-svn: 335680

llvm-svn: 335677

llvm-svn: 335676

Summary:
When recording uses we need to rewrite after cloning a loop we need to
check if the use is not dominated by the original def. The initial
assumption was that the cloned basic block will introduce a new path and
thus the original def will only dominate the use if they are in the same
BB, but as the reproducer from PR37745 shows it's not always the case.

This fixes PR37745.

Reviewers: haicheng, Ka-Ka

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 335675

This generalizes the old heuristic placing SHT_DYNSYM SHT_DYNSTR first in the readonly SHF_ALLOC segment.

Reviewers: espindola

Subscribers: emaste, arichardson, llvm-commits

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

llvm-svn: 335674

llvm-svn: 335673

Instead of just saying "flag unused", we should tell the user that the
outliner isn't (at least officially) supported for some given architecture.

This adds a warning that will state something like

The 'blah' architecture does not support -moutline; flag ignored

when we call -moutline with the 'blah' architecture.

Since the outliner is still mostly an AArch64 thing, any architecture
other than AArch64 will emit this warning.

llvm-svn: 335672

llvm-svn: 335671

LLJIT is a prefabricated ORC based JIT class that is meant to be the go-to
replacement for MCJIT. Unlike OrcMCJITReplacement (which will continue to be
supported) it is not API or bug-for-bug compatible, but targets the same
use cases: Simple, non-lazy compilation and execution of LLVM IR.

LLLazyJIT extends LLJIT with support for function-at-a-time lazy compilation,
similar to what was provided by LLVM's original (now long deprecated) JIT APIs.

This commit also contains some simple utility classes (CtorDtorRunner2,
LocalCXXRuntimeOverrides2, JITTargetMachineBuilder) to support LLJIT and
LLLazyJIT.

Both of these classes are works in progress. Feedback from JIT clients is very
welcome!

llvm-svn: 335670

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

llvm-svn: 335669

Recommit of r335658 so that it does not change the behaviour of any
existing error output.

llvm-svn: 335668

This addresses post-commit feedback about the name 'skipDebugInfo' being
misleading. This name could be interpreted as meaning 'a function that
skips instructions with debug locations'.

The new name, 'skipDebugIntrinsics', makes it clear that this function
only skips debug info intrinsics.

Thanks to Adrian Prantl for pointing this out!

llvm-svn: 335667

In the current implementation, we run visitors until the fixed point is
reached.
That is, if a visitor adds another visitor, the currently processed path
is destroyed, all diagnostics is discarded, and it is regenerated again,
until it's no longer modified.
This pattern has a few negative implications:

 - This loop does not even guarantee to terminate.
   E.g. just imagine two visitors bouncing a diagnostics around.
 - Performance-wise, e.g. for sqlite3 all visitors are being re-run at
   least 10 times for some bugs.
   We have already seen a few reports where it leads to timeouts.
 - If we want to add more computationally intense visitors, this will
   become worse.
 - From architectural standpoint, the current layout requires copying
   visitors, which is conceptually wrong, and can be annoying (e.g. no
   unique_ptr on visitors allowed).

The proposed change is a much simpler architecture: the outer loop
processes nodes upwards, and whenever the visitor is added it only
processes current nodes and above, thus guaranteeing termination.

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

llvm-svn: 335666

Also give the constructor's transform parameter a default no-op transform value.

llvm-svn: 335665

AsynchronousSymbolQuery::canStillFail checks the value of the callback to
prevent sending it redundant error notifications, so we need to reset it after
running it.

llvm-svn: 335664

llvm-svn: 335663

llvm-svn: 335662

llvm-svn: 335661

This reverts commit 4850a9aae8b38c7deadc103d634ec7397e6c323b.

It caused MC/X86/x86_errors.s to fail. Will fix and recommit shortly.

llvm-svn: 335660

llvm-svn: 335659

Right now, when we use RIP-relative instructions in 32-bit mode, we'll just
assert and crash.

This adds an error message which tells the user that they can't do that in
32-bit mode, so that we don't crash (and also can see the issue outside of
assert builds).

llvm-svn: 335658

llvm-svn: 335657

r335599 changes usages of AddressClass, but doesn't change the type itself.

llvm-svn: 335656

llvm-svn: 335655

This intrinsic selects v_mad_f32 regardless of fp32 denorm support.

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

llvm-svn: 335654

FreeBSD defaults to mips3 for all MIPS ABIs with GCC as that is the
minimum MIPS architecture FreeBSD supports.  Use mips3 for MIPS64 and
mips2 for MIPS32 to match.

Reviewed By: atanasyan

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

llvm-svn: 335653