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

llvm-svn: 322360

AT> lma_region expression allows to specify the memory region
for section load address.

Should fix PR35684.

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

llvm-svn: 322359

Re-enable Select after a couple of fixes.

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

llvm-svn: 322358

This is a fix for PR35884.

When we want to delete dead loop we must clean uses in unreachable blocks
otherwise we'll get an assert during deletion of instructions from the loop.

Reviewers: anna, davide
Reviewed By: anna
Subscribers: llvm-commits, lebedev.ri
Differential Revision: https://reviews.llvm.org/D41943

llvm-svn: 322357

[X86] Don't allow lods/stos/scas/cmps/movs to be parsed without a suffix and only memory operand in at&t syntax.

Without a register with a size being mentioned the instruction is ambiguous in at&t syntax. With Intel syntax the memory operation caries a size that can be used to disambiguate.

llvm-svn: 322356

llvm-svn: 322355

While the suffix isn't required to disambiguate the instructions, it is required in order to parse the instructions when the suffix is specified in order to match the GNU assembler.

llvm-svn: 322354

llvm-svn: 322353

llvm-svn: 322352

As mentioned by EricWF in revision D41830

llvm-svn: 322351

In certain combinations of templated classes and friend functions, the body
of friend functions does not get propagated along with function signature.
Exclude friend functions for hashing to avoid this case.

llvm-svn: 322350

Summary:
Currently LLVM has no way to support configuring for IDE's like CLion. Like XCode and MSVC's IDE, CLion needs to see all of the headers and tablegen files in order to properly parse the sources.

This patch adds an `LLVM_ENABLE_IDE` option which can be used to configure for IDE's in general. It is used by `LLVMProcessSources.cmake` to determine if the extra source files should be added to the target.

Unfortunately because of the low level of `LLVMProcessSources.cmake`, I'm not sure where the `LLVM_ENABLE_IDE` option should live. I choose `HandleLLVMOptions.cmake` so that out-of-tree Clang builds would correctly configure the option by default.



Reviewers: beanz, mgorny, lebedev.ri

Reviewed By: beanz

Subscribers: llvm-commits

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

llvm-svn: 322349

RemoveInvalidLocations was clearing out the m_locations in the
breakpoint by hand, and it wasn't also clearing the locations from
the address->location map, which confused us when we went to update
breakpoint locations.  

I also made Breakpoint::ModulesChanged check the Location's Section
to make sure it hadn't been deleted.  This shouldn't strictly be necessary,
but if the DynamicLoaderPlugin doesn't do it's job right (I'm looking at
you new Darwin DynamicLoader...) then it can end up leaving stale locations
on rerun.  It doesn't hurt to clean them up here as a backstop.

<rdar://problem/36134350>

llvm-svn: 322348

llvm-svn: 322347

llvm-svn: 322346

Summary:

This change allows checking for ISA extensions in print methods.

Reviewers: asb, niosHD

Reviewed By: asb, niosHD

Subscribers: llvm-commits, niosHD, asb, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal

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

llvm-svn: 322345

llvm-svn: 322344

The spec doesn't allow this.

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

llvm-svn: 322343

llvm-svn: 322342

llvm-svn: 322341

This test stresses expression evaluation support for template functions.
Currently the support is rudimentary, and running this test causes assertion
failures in clang. This test cannot be XFAIL'ed because the test harness
treats assertion failures as unexpected events. For now, the test must be
skipped.

llvm-svn: 322340

been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProcessInfo), and the target.xml
includes a <architecture> tag specifying x86_64, set the architecture
appropriately.

I'm not sure what we can expect to see in the <architecture> tag, so
I'm only doing this for x86_64 right now where I've seen "i386:x86_64"
used.  I've seen a target.xml from a jtag board that sends just "arm"
because it doesn't know more specifically what type of board it is
connected to...  

<rdar://problem/29908970> 

llvm-svn: 322339

This is failing on the bot but not locally.  Maybe
the error message will tell us why.

llvm-svn: 322338

llvm-svn: 322337

ExecutionSession will represent a running JIT program.

VModuleKey is a unique key assigned to each module added as part of
an ExecutionSession. The Layer concept will be updated in future to
require a VModuleKey when a module is added.

llvm-svn: 322336

Summary:
This revision causes Skylake (and apparently, only Skylake) codegen to fail in
certain cases. Details: https://bugs.llvm.org/show_bug.cgi?id=35918

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 322335

Summary:
The STL types `std::pair` and `std::tuple` can both store reference types. However their constructors cannot adequately check if the initialization of reference types is safe.  For example:

```
std::tuple<std::tuple<int> const&> t = 42;
// The stored reference is already dangling.
```

Libc++ has a best effort attempts in tuple to diagnose this, but they're not able to handle all valid cases (If I'm not mistaken). For example initialization of a reference from the result of a class's conversion operator.  Libc++ would benefit from having a builtin traits which can provide a much better implementation.

This patch introduce the `__reference_binds_to_temporary(T, U)` trait  that determines whether a reference of type `T` bound to an expression of type `U` would bind to a materialized temporary object.

Note that the trait simply returns false if `T` is not a reference type instead of reporting it as an error.

```
static_assert(__is_constructible(int const&, long));
static_assert(__reference_binds_to_temporary(int const&, long));
```


Reviewers: majnemer, rsmith

Reviewed By: rsmith

Subscribers: compnerd, cfe-commits

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

llvm-svn: 322334

Summary:
This argument (the isUsed flag) seems to only be relevant
when parsing.  Other calls sites such as these don't seem
to ever use it.

Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish

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

llvm-svn: 322332

Thanks Jason.

llvm-svn: 322329

target.IsValid() not target...

llvm-svn: 322328

This doesn't handle the more complicated case in the bug report yet:
https://bugs.llvm.org/show_bug.cgi?id=35790

For that, we have to match / look through a cast.

llvm-svn: 322327

It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p9:
  [...] In any case, if n is greater than zero it then stores a null
  character into the next successive location of the array.

rdar://problem/35566567

Reviewers: EricWF, mclow.lists

Reviewed By: mclow.lists

Subscribers: cfe-commits

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

llvm-svn: 322326

- Less unnecessary use of `auto`
- Add early `using RegSubRegPair(AndIdx) =` to avoid countless
  `TargetInstrInfo::` qualifications.
- Use references instead of pointers where possible.
- Remove unused parameters.
- Rewrite the CopyRewriter class hierarchy:
   - Pull out uncoalescable copy rewriting functionality into
     PeepholeOptimizer class.
   - Use an abstract base class to make it clear that rewriters are
     independent.
- Remove unnecessary \brief in doxygen comments.
- Remove unused constructor and method from ValueTracker.
- Replace UseAdvancedTracking of ValueTracker with DisableAdvCopyOpt use.

llvm-svn: 322325

Summary:
Very basic stack instrumentation using tagged pointers.
Tag for N'th alloca in a function is built as XOR of:
 * base tag for the function, which is just some bits of SP (poor
   man's random)
 * small constant which is a function of N.

Allocas are aligned to 16 bytes. On every ReturnInst allocas are
re-tagged to catch use-after-return.

This implementation has a bunch of issues that will be taken care of
later:
1. lifetime intrinsics referring to tagged pointers are not
   recognized in SDAG. This effectively disables stack coloring.
2. Generated code is quite inefficient. There is one extra
   instruction at each memory access that adds the base tag to the
   untagged alloca address. It would be better to keep tagged SP in a
   callee-saved register and address allocas as an offset of that XOR
   retag, but that needs better coordination between hwasan
   instrumentation pass and prologue/epilogue insertion.
3. Lifetime instrinsics are ignored and use-after-scope is not
   implemented. This would be harder to do than in ASan, because we
   need to use a differently tagged pointer depending on which
   lifetime.start / lifetime.end the current instruction is dominated
   / post-dominated.

Reviewers: kcc, alekseyshl

Subscribers: srhines, kubamracek, javed.absar, hiraditya, llvm-commits

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

llvm-svn: 322324

llvm-svn: 322323

That never really worked, and the change associated isn't yet
committed, so, let's try to make the bots green for now.

llvm-svn: 322322

See: https://github.com/WebAssembly/tool-conventions/issues/35

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

llvm-svn: 322321

This allows libraries to supply a list of symbols which are
allowed to be undefined at link time (i.e. result in imports).

This method replaces the existing mechanism (-allow-undefined-file)
used by the clang driver to allow undefined symbols in libc.

For more on motivation for this see:
 https://github.com/WebAssembly/tool-conventions/issues/35

In the long run we hope to remove this features and instead
include this information in the object format itself.

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

llvm-svn: 322320

The PeepholeOptimizer would fail for vregs without a definition. If this
was caused by an undef operand abort to keep the code simple (so we
don't need to add logic everywhere to replicate the undef flag).

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

llvm-svn: 322319

While updating clang tests for having clang set dso_local I noticed
that:

- There are *a lot* of tests to update.
- Many of the updates are redundant.

They are redundant because a GV is "obviously dso_local". This patch
starts formalizing that a bit by requiring that internal and private
GVs be dso_local too. Since they all are, we don't have to print
dso_local to the textual representation, making it a bit more compact
and easier to read.

llvm-svn: 322318