This reverts commit r334543.

My understanding is, that commit is intended to make the llvm-build
invocation have a correct "--enable-optional-components" value, but:
- it already has a value: it's quoted in the command line a few lines
  below, and, if I hack llvm-build to print sys.argv, it does look correct:
    -- llvm-build output: ['.../utils/llvm-build/llvm-build',
      '--native-target', 'X86', '--enable-targets', 'X86;ARM;AArch64',
      '--enable-optional-components', '',
      '--write-library-table',
      '.../build/tools/llvm-config/LibraryDependencies.inc',
      '--write-cmake-fragment', '.../build/LLVMBuild.cmake']
- the " " string seems to evaluate to TRUE in CMake (*sigh*), so this
  basically force-enables LLVM_USE_INTEL_JITEVENTS, regardless of the
  value of the option.
  On Darwin, JITEvents is not supported, so this bypasses that OS check
  but is guaranteed to fail later.

llvm-svn: 334566

[X86] Mark all instructions that have masked store semantics with NotMemoryFoldable. Remove dependency on SchedRW from memory table autogenerator.

Previously we were whitelisting in instructions based on their SchedRW value. With the masked store instructions explicitly removed via NotMemoryFoldable, we don't seem to need this check anymore.

llvm-svn: 334563

llvm-svn: 334562

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

llvm-svn: 334559

llvm-svn: 334556

We use size_t in this header, so we also need to include
cstddef to make it compile. Fixes the module builds.

llvm-svn: 334555

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

llvm-svn: 334553

llvm-svn: 334551

llvm-svn: 334547

llvm-svn: 334544

Patch by Force.Charlie-I

If LLVM_USE_INTEL_JITEVENTS and LLVM_USE_OPROFILE  not set,
"${LLVMOPTIONALCOMPONENTS}" is empty, but
**--enable-optional-components** need arg, Cause
**--write-library-table** to be skipped parsed.

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

llvm-svn: 334543

If a VSO has a fallback definition generator attached it will be called during
lookup (and lookupFlags) for any unresolved symbols. The definition generator
can add new definitions to the VSO for any unresolved symbol. This allows VSOs
to generate new definitions on demand.

The immediate use case for this code is supporting VSOs that can import
definitions found via dlsym on demand.

llvm-svn: 334538

implement existing blocking lookups (the lookup function) and
JITSymbolResolverAdapter on top of that.

llvm-svn: 334537

Resolvers are required to find results for all requested symbols or return an
error, but if a resolver fails to adhere to this contract (by returning results
for only a subset of the requested symbols) then this code will infinite loop.
This assertion catches resolvers that fail to adhere to the contract.

llvm-svn: 334536

This only affects modules with lazy GVMaterializers attached (usually modules
read off disk using the lazy bitcode reader). For such modules, materializing
before compiling prevents crashes due to missing function bodies /
initializers.

llvm-svn: 334535

Register x20 is a callee-saved register which may be used for other
purposes in certain contexts, for example to hold special variables
within the kernel. This change adds support for reserving this register
both to frontend and backend to make this register usable for these
purposes.

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

llvm-svn: 334531

llvm-svn: 334530

llvm-svn: 334529

All COFF targets should use @IMGREL32 relocations for symbol differences
against __ImageBase. Do the same for getSectionForConstant, so that
immediates lowered to globals get merged across TUs.

Patch by Chris January

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

llvm-svn: 334523

- Move section selection and alignment to AMDGPUAsmPrinter

llvm-svn: 334521

Apparently, MachineInstr class definition as well as pretty much all of
the machine passes assume that the only kind of MachineInstr's operands
that is variadic for variadic opcodes is explicit non-definitions.

In particular, this assumption is made by MachineInstr::defs(), uses(),
and explicit_uses() methods, as well as by MachineCSE pass.

The assumption is incorrect judging from at least TableGen backend
implementation, that recognizes variable_ops in OutOperandList, and the
very existence of G_UNMERGE_VALUES generic opcode, or ARM load multiple
instructions, all of which have variadic defs.

In particular, MachineCSE pass breaks MIR with CSE'able G_UNMERGE_VALUES
instructions in it.

This commit implements MachineInstr::getNumExplicitDefs() similar to
pre-existing MachineInstr::getNumExplicitOperands(), fixes
MachineInstr::defs(), uses(), and explicit_uses(), and fixes MachineCSE
pass.

As the issue addressed seems to affect only machine passes that could be
ran mid-GlobalISel pipeline at the moment, the other passes aren't fixed
by this commit, like MachineLICM: that could be done on per-pass basis
when (if ever) they get adopted for GlobalISel.

Reviewed By: arsenm

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

llvm-svn: 334520

- Do not emit following assembler directives:
  - .hsa_code_object_version
  - .hsa_code_object_isa
  - .amd_amdgpu_isa
  - .amd_amdgpu_hsa_metadata
  - .amd_amdgpu_pal_metadata
- Do not emit .note entries
- Cleanup and bring in sync kernel descriptor header file
- Emit kernel descriptor into .rodata with appropriate relocations and
  alignments

llvm-svn: 334519

This simplifies some code which had StringRefs to begin with, and
makes other code more complicated which had const char* to begin
with.

In the end, I think this makes for a more idiomatic and platform
agnostic API.  Not all platforms launch process with null terminated
c-string arrays for the environment pointer and argv, but the api
was designed that way because it allowed easy pass-through for
posix-based platforms.  There's a little additional overhead now
since on posix based platforms we'll be takign StringRefs which
were constructed from null terminated strings and then copying
them to null terminate them again, but from a readability and
usability standpoint of the API user, I think this API signature
is strictly better.

llvm-svn: 334518

[MC] [X86] Teach leaq _GLOBAL_OFFSET_TABLE(%rip), %r15 to use R_X86_64_GOTPC32 instead of R_X86_64_PC32

Summary:
This is similar to D46319 (ARM). x86-64 psABI p40 gives an example:

  leaq _GLOBAL_OFFSET_TABLE(%rip), %r15 # GOTPC32 reloc

GNU as creates R_X86_64_GOTPC32. However, MC currently emits R_X86_64_PC32.

Reviewers: javed.absar, echristo

Subscribers: kristof.beyls, llvm-commits, peter.smith, grimar

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

llvm-svn: 334515

Summary: This patch originated from D46562 and is a proper subset, with some issues addressed for fmul.

Reviewers: spatel, hfinkel, wristow, arsenm

Reviewed By: spatel

Subscribers: nhaehnle, wdng

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

llvm-svn: 334514

As discussed on PR33744, this patch relaxes ShuffleKind::SK_Alternate which requires shuffle masks to only match an alternating pattern from its 2 sources:

e.g. v4f32: <0,5,2,7> or <4,1,6,3>

This seems far too restrictive as most SIMD hardware which will implement it using a general blend/bit-select instruction, so replaces it with SK_Select, permitting elements from either source as long as they are inline:

e.g. v4f32: <0,5,2,7>, <4,1,6,3>, <0,1,6,7>, <4,1,2,3> etc.

This initial patch just updates the name and cost model shuffle mask analysis, later patch reviews will update SLP to better utilise this - it still limits itself to SK_Alternate style patterns.

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

llvm-svn: 334513

Don't provide the assembler source as the "root file" unless the user
asked to have debug info for the assembler source (with -g).

If the source doesn't provide an explicit ".file 0" then (a) use the
compilation directory as directory #0, and (b) use the file #1 info
for file #0 also.

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

llvm-svn: 334512

llvm-svn: 334511

llvm-svn: 334509

llvm-svn: 334508

As discussed on D47985, identity shuffle masks should probably be free.

I've limited this to the case where the input and output types all match - but we could probably accept all cases.

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

llvm-svn: 334506

We should be able to obsolete D48043 by easing the constraints
on this existing code. 

llvm-svn: 334504

Summary: This allows handling memory ports on SNB.

Reviewers: gchatelet

Subscribers: tschuett, llvm-commits

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

llvm-svn: 334502

Summary: This patch moves linking of libpfm from different places to a single one.

Reviewers: courbet

Subscribers: mgorny, tschuett, llvm-commits

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

llvm-svn: 334499

Implement default legalization of rotates: either in terms of the rotation
in the opposite direction (if legal), or in terms of shifts and ors.

Implement generating of rotate instructions for Hexagon. Hexagon only
supports rotates by an immediate value, so implement custom lowering of
ROTL/ROTR on Hexagon. If a rotate is not legal, use the default expansion.

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

llvm-svn: 334497

Currently SmallSet<PointerTy> inherits from SmallPtrSet<PointerTy>. This
patch replaces such types with SmallPtrSet, because IMO it is slightly
clearer and allows us to get rid of unnecessarily including SmallSet.h

Reviewers: dblaikie, craig.topper

Reviewed By: dblaikie

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

llvm-svn: 334492

Reviewers: smaksimovic, atanasyan, abeserminji

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

llvm-svn: 334491

Extend LONG_BRANCH_LUi and LONG_BRANCH_ADDiu pseudo instructions with
additional flag, so instead of always lowering to lui %hi(...),
addiu %lo(...) or addiu %hi(...), now they can lower to either %lo, %hi,
%higher or %highest depending on the added flag.

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

llvm-svn: 334490

llvm-svn: 334488

llvm-svn: 334486