Summary:
Adds the standard gauntlet of accessors for global indirect functions and updates the echo test.

Now it would be nice to have a target abstraction so one could know if they have access to a suitable ELF linker and runtime.

Reviewers: whitequark, deadalnix

Reviewed By: whitequark

Subscribers: llvm-commits

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

llvm-svn: 353193

Patch by Kristina Bessonova!

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

llvm-svn: 353192

Type punning through a union -> no good.
double to uint64 to double again -> no good either.

The nice side effect, other than silencing the sanitizer bot
is that it fixes the formatting of some dates, e.g. Jan 1st 1970.

<rdar://problem/47617983>

llvm-svn: 353191

We can't outline BTI instructions, because they need to be the very first
instruction executed after an indirect call or branch. If we outline them, then
an indirect call might go to the branch to the outlined function, which will
fault.

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

llvm-svn: 353190

llvm-svn: 353189

This is equivalent to clampMaxNumElements, but saves a check.

llvm-svn: 353188

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

llvm-svn: 353187

The fix is to issue error messages if there are more than one 
teams construct inside a target constructs.

#pragma omp target
{
  #pragma omp teams
  {  ...  }

  #pragma omp teams
  { ... }
}

llvm-svn: 353186

llvm-svn: 353185

Emit{Nounwind,}RuntimeCall{,OrInvoke} have been modified to take a
FunctionCallee as an argument, and CreateRuntimeFunction has been
modified to return a FunctionCallee. All callers have been updated.

Additionally, CreateBuiltinFunction is removed, as it was redundant
with CreateRuntimeFunction after some previous changes.

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

llvm-svn: 353184

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

llvm-svn: 353183

llvm-svn: 353182

edge cases.

Currently, EmitCall emits a call instruction with a function type
derived from the pointee-type of the callee. This *should* be the same
as the type created from the CallInfo parameter, but in some cases an
incorrect CallInfo was being passed.

All of these fixes were discovered by the addition of the assert in
EmitCall which verifies that the passed-in CallInfo matches the
Callee's function type.

As far as I know, these issues caused no bugs at the moment, as the
correct types were ultimately being emitted. But, some would become
problematic when pointee types are removed.

List of fixes:

* arrangeCXXConstructorCall was passing an incorrect value for the
  number of Required args, when calling an inheriting constructor
  where the inherited constructor is variadic. (The inheriting
  constructor doesn't actually get passed any of the user's args, but
  the code was calculating it as if it did).

* arrangeFreeFunctionLikeCall was not including the count of the
  pass_object_size arguments in the count of required args.

* OpenCL uses other address spaces for the "this" pointer. However,
  commonEmitCXXMemberOrOperatorCall was not annotating the address
  space on the "this" argument of the call.

* Destructor calls were being created with EmitCXXMemberOrOperatorCall
  instead of EmitCXXDestructorCall in a few places. This was a problem
  because the calling convention sometimes has destructors returning
  "this" rather than void, and the latter function knows about that,
  and sets up the types properly (through calling
  arrangeCXXStructorDeclaration), while the former does not.

* generateObjCGetterBody: the 'objc_getProperty' function returns type
  'id', but was being called as if it returned the particular
  property's type. (That is of course the *dynamic* return type, and
  there's a downcast immediately after.)

* OpenMP user-defined reduction functions (#pragma omp declare
  reduction) can be called with a subclass of the declared type. In
  such case, the call was being setup as if the function had been
  actually declared to take the subtype, rather than the base type.

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

llvm-svn: 353181

llvm-svn: 353180

llvm-svn: 353179

llvm-svn: 353178

Patch from Mirko Bonadei <mbonadei@webrtc.org>!

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

llvm-svn: 353177

llvm-svn: 353176

llvm-svn: 353175

llvm-svn: 353174

Summary:
While the backend code of FileCheck relies on definition of variable
from the command-line to have an equal sign '=' and a variable name
before that, the frontend does not actually enforce it. This leads to
FileCheck crashing when invoked with invalid syntax for the -D option.

This patch adds the missing validation in the frontend. It also makes
the -D option an AlwaysPrefix option to be able to detect -D=FOO as
being a define without variable and -D as missing its value.

Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions)

Reviewers: jdenny

Subscribers: JonChesterfield, hiraditya, kristina, probinson,
llvm-commits

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

llvm-svn: 353173

Summary:
Add support for options that always prefix their value, giving an error
if the value is in the next argument or if the option is given a value
assignment (ie. opt=val). This is the desired behavior for the -D option
of FileCheck for instance.

Copyright:
- Linaro (changes in version 2 of revision D55940)
- GraphCore (changes in later versions and introduced when creating
  D56549)

Reviewers: jdenny

Subscribers: llvm-commits, probinson, kristina, hiraditya,
JonChesterfield

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

llvm-svn: 353172

I'm going to be adding SimplifyDemandedBits tests shortly.

llvm-svn: 353171

DispatchStage should always delegate to an object of class RegisterFile the task
of updating data dependencies.  ReadState and WriteState objects should not be
modified directly by DispatchStage.
This patch also renames stage IS_AVAILABLE to IS_DISPATCHED.

llvm-svn: 353170

Trivial fix: decode was not called for all subprocess.check_output calls.

Commited on behalf of Andrew Boyarshin

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

llvm-svn: 353168

llvm-svn: 353165

llvm-svn: 353164

When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets
the default standard to something other than C++14, there are a number of lit
tests that fail as they rely on the C++14 default.
This patch just adds the language standard option explicitly to such test cases.

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

llvm-svn: 353163

In some cases, it is faster to just grow the set of 'Users' rather than
performing a llvm::find_if every time a new user is added to
the set. No functional change intended.

llvm-svn: 353162

Summary:
```
ClangExpressionDeclMap.cpp:72:60: error: field 'm_struct_vars' will be initialized after field 'm_ctx_obj' [-Werror,-Wreorder]
      m_result_delegate(result_delegate), m_parser_vars(), m_struct_vars(),
```

Reviewers: bkramer, aleksandr.urakov

Reviewed By: aleksandr.urakov

Subscribers: aleksandr.urakov

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

llvm-svn: 353161

When we attempt to add an addr space qual to a type already
qualified by an addr space ICE is triggered. Before creating
a type with new address space, remove the old addr space.

Fixing PR38614!

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

llvm-svn: 353160

Some use cases are appearing where salvaging is needed that does not
correspond to an instruction being deleted -- for example an instruction
being sunk, or a Value not being available in a block being isel'd.

Enable more fine grained control over how salavging occurs by splitting
the logic into helper functions, separating things that are specific to
working on DbgVariableIntrinsics from those specific to interpreting IR
and building DIExpressions.

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

llvm-svn: 353156

The test started failing for me recently. I don't see any changes around
this code, so maybe it's my local go version that changed or something.

The error seems real to me: we're trying to print an Attribute with %d.
The test talks about "attribute masks" I'm not sure what that refers to,
but I suppose we could print the raw pointer value, since that's
what the test seems to be comparing.

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

llvm-svn: 353155

If we have broadcasts of different vector widths, keep the longest vector width and extract subvectors for the shorter vectors (which should be free).

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

llvm-svn: 353154

llvm-svn: 353153

This patch improves code generation for some AArch64 ACLE intrinsics. It adds
support to CGP to duplicate and sink operands to their user, if they can be
folded into a target instruction, like zexts and sub into usubl. It adds a
TargetLowering hook shouldSinkOperands, which looks at the operands of
instructions to see if sinking is profitable.

I decided to add a new target hook, as for the sinking to be profitable,
at least on AArch64, we have to look at multiple operands of an
instruction, instead of looking at the users of a zext for example.

The sinking is done in CGP, because it works around an instruction
selection limitation. If instruction selection is not limited to a
single basic block, this patch should not be needed any longer.

Alternatively this could be done in the LoopSink pass, which tries to
undo LICM for instructions in blocks that are not executed frequently.

Note that we do not force the operands to sink to have a single user,
because we duplicate them before sinking. Therefore this is only
desirable if they really can be done for free. Additionally we could
consider the impact on live ranges later on.

This should fix https://bugs.llvm.org/show_bug.cgi?id=40025.

As for performance, we have internal code that uses intrinsics and can
be speed up by 10% by this change.

Reviewers: SjoerdMeijer, t.p.northover, samparker, efriedma, RKSimon, spatel

Reviewed By: samparker

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

llvm-svn: 353152

Same as ARM, but use a different opcode in the instruction selection.

llvm-svn: 353151

llvm-svn: 353150

Summary:
This patch adds support of expression evaluation in a context of some object.
Consider the following example:
```
struct S {
  int a = 11;
  int b = 12;
};

int main() {
  S s;
  int a = 1;
  int b = 2;
  // We have stopped here
  return 0;
}
```
This patch allows to do something like that:
```
lldb.frame.FindVariable("s").EvaluateExpression("a + b")
```
and the result will be `33` (not `3`) because fields `a` and `b` of `s` will be
used (not locals `a` and `b`).

This is achieved by replacing of `this` type and object for the expression. This
has some limitations: an expression can be evaluated only for values located in
the debuggee process memory (they must have an address of `eAddressTypeLoad`
type).

Reviewers: teemperor, clayborg, jingham, zturner, labath, davide, spyffe, serge-sans-paille

Reviewed By: jingham

Subscribers: abidh, lldb-commits, leonid.mashinskiy

Tags: #lldb

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

llvm-svn: 353149

LLVM_ENABLED_PROJECT and reconfigured it had no effect on what
projects were actually built. This was very confusing behaviour. The
reason for this is that the value of the `LLVM_TOOL_<PROJECT>_BUILD`
variables are already set.

The problem here is that we have two sources of truth:

* The projects listed in LLVM_ENABLE_PROJECTS.
* The projects enabled/disabled with LLVM_TOOL_<PROJECT>_BUILD.

At configure time we have no real way of knowing which source of truth
the user wants so we apply the following heuristic:

If the user ever sets `LLVM_ENABLE_PROJECTS` in the CMakeCache then that
is used as the single source of truth and we force the
`LLVM_TOOL_<PROJECT>_BUILD` CMake cache variables to have the
appropriate values that match the contents of the
`LLVM_ENABLE_PROJECTS`. If the user never sets `LLVM_ENABLE_PROJECTS`
then they can continue to use and set the `LLVM_TOOL_<PROJECT>_BUILD`
variables as the "source of truth".

The problem with this approach is that if the user ever tries to use
both `LLVM_ENABLE_PROJECTS` and `LLVM_TOOL_<PROJECT>_BUILD` for the same
build directory then any user set value for `LLVM_TOOL_<PROJECT>_BUILD`
variables will get overwriten, likely without the user noticing.

Hopefully the above shouldn't matter in practice because the
LLVM_TOOL_<PROJECT>_BUILD variables are not documented, but
LLVM_ENABLE_PROJECTS is.

We should probably deprecate the `LLVM_TOOL_<PROJECT>_BUILD`
variables at some point by turning them into to regular CMake
variables that don't live in the CMake cache.

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

llvm-svn: 353148