Identified by Pedro Giffuni in PR27636.

llvm-svn: 287487

Identified by Pedro Giffuni in PR27636.

llvm-svn: 287486

The change is part of RegCall calling convention support for LLVM.
Long double (f80) requires special treatment as the first f80 parameter is saved in FP0 (floating point stack).
This review present the change and the corresponding tests.

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

llvm-svn: 287485

Fixing a wrong comment on X86AsmParser.cpp::ParseZ: "true" --> "false"

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

llvm-svn: 287484

If a response file in construct `@file` was specified by relative name,
constructs `@file` nested within it were resolved incorrectly if the
flag RelativeNames in call to ExpandResponseFile was set to true.
This feature is used in configuration files, tests for it are in
respective change (see D24933).

llvm-svn: 287482

The casting based reading of the LSDA could attempt to read unsuitably aligned
data.  Avoid that case by explicitly using a memcpy.  A similar approach is used
in libc++abi to address the same UB.

llvm-svn: 287479

Rather than redeclaring the interfaces for exceptions, prefer using the
`unwind.h` header.  This is vended by at least gcc and clang, and can also be
found by an external unwinding library (e.g. libunwind).  Doing this simplifies
the example to the exception handling itself.  Minor tweaks are the result of
_Unwind_Context_t not being defined, which is just a typedef for struct
_Unwind_Context *.  NFC.

llvm-svn: 287478

add BPF disassembler, so tools like llvm-objdump can be used:
$ llvm-objdump -d -no-show-raw-insn ./sockex1_kern.o

./sockex1_kern.o:	file format ELF64-BPF

Disassembly of section socket1:
bpf_prog1:
       0:	r6 = r1
       8:	r0 = *(u8 *)skb[23]
      10:	*(u32 *)(r10 - 4) = r0
      18:	r1 = *(u32 *)(r6 + 4)
      20:	if r1 != 4 goto 8
      28:	r2 = r10
      30:	r2 += -4

ld_imm64 (the only 16-byte insn) and special ld_abs/ld_ind instructions
had to be treated in a special way. The decoders for the rest of the insns
are automatically generated.

Add tests to cover new functionality.

Signed-off-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 287477

llvm-svn: 287476

llvm-svn: 287475

llvm-svn: 287474

This code is taken from public domain.
https://github.com/jsonn/src/blob/trunk/common/lib/libc/hash/sha1/sha1.c

I wrote a sha1 command and ran it on my Xeon E5-2680 v2 2.80GHz machine.
Here is a result. The new hash function is 37% faster than before.

 Performance counter stats for './llvm-sha1-old /ssd/build/bin/lld' (10 runs):

       6640.503687 task-clock (msec)         #    1.001 CPUs utilized            ( +-  0.03% )
                54 context-switches          #    0.008 K/sec                    ( +-  5.03% )
                 5 cpu-migrations            #    0.001 K/sec                    ( +- 31.73% )
           183,803 page-faults               #    0.028 M/sec                    ( +-  0.00% )
    18,527,954,113 cycles                    #    2.790 GHz                      ( +-  0.03% )
     4,993,237,485 stalled-cycles-frontend   #   26.95% frontend cycles idle     ( +-  0.11% )
   <not supported> stalled-cycles-backend
    50,217,149,423 instructions              #    2.71  insns per cycle
                                             #    0.10  stalled cycles per insn  ( +-  0.00% )
     6,094,322,337 branches                  #  917.750 M/sec                    ( +-  0.00% )
        11,778,239 branch-misses             #    0.19% of all branches          ( +-  0.01% )

       6.634017401 seconds time elapsed                                          ( +-  0.03% )

 Performance counter stats for './llvm-sha1-new /ssd/build/bin/lld' (10 runs):

       4167.062720 task-clock (msec)         #    1.001 CPUs utilized            ( +-  0.02% )
                52 context-switches          #    0.012 K/sec                    ( +- 16.45% )
                 7 cpu-migrations            #    0.002 K/sec                    ( +- 32.20% )
           183,804 page-faults               #    0.044 M/sec                    ( +-  0.00% )
    11,626,611,958 cycles                    #    2.790 GHz                      ( +-  0.02% )
     4,491,897,976 stalled-cycles-frontend   #   38.63% frontend cycles idle     ( +-  0.05% )
   <not supported> stalled-cycles-backend
    24,320,180,617 instructions              #    2.09  insns per cycle
                                             #    0.18  stalled cycles per insn  ( +-  0.00% )
     1,574,674,576 branches                  #  377.886 M/sec                    ( +-  0.00% )
        11,769,693 branch-misses             #    0.75% of all branches          ( +-  0.00% )

       4.163251552 seconds time elapsed                                          ( +-  0.02% )

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

llvm-svn: 287473

The demangler had stopped using a custom allocator but had not been updated to
remove the use of the explicit allocator passing.  This removes that as we do
not need to do anything special here anymore.  This just makes the code more
compact.  NFC.

llvm-svn: 287472

We could create a local typedef for std::vector called Vector.  Inline the use
of std::vector rather than use the typedef.  NFC.

llvm-svn: 287471

We created a local typedef for `std::basic_string<char, std::char_traits<char>>`
which is just `std::string`.  Remove the local typedef and propagate the type
information through the rest of the demangler.  NFC.

llvm-svn: 287470

Prefer direct member initialization over the explicit out-of-line initialization
for the construction of the local type.  NFC.

llvm-svn: 287469

llvm-svn: 287462

Canonicalization may leave the zeroable vector in the first input.

llvm-svn: 287461

llvm-svn: 287459

It seems that because ThinLTO does not import the full module,
some invariant of the type mapper are broken.

In Monolithic LTO, we import every globals: when calling
IRLinker::copyFunctionProto() on @foo(), we end-up calling
TypeMapTy::get(FTy) on the type of @foo(), which will map
%0 and record the destination as opaque.

ThinLTO skips this because @foo is not imported and goes directly
to the next stage.

Next we call computeTypeMapping() that map the types for each
globals, and ends up checking for type isomorphism, and may add
type mapping. However it doesn't record if there was an opaque
destination type that was resolved.

Instead of lazily "discovering" opaque type in the destination
module on the go, we change the TypeFinder to eagerly record all
types and not only the named ones.

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

llvm-svn: 287453

Summary:
This will also be added to the LTO API, right now this will
bring ThinLTO on par with Monolithic LTO on Darwin.

Reviewers: anemet

Subscribers: tejohnson, llvm-commits

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

llvm-svn: 287450

Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.

Reviewers: anemet

Subscribers: llvm-commits

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

llvm-svn: 287449

llvm-svn: 287447

llvm-svn: 287444

[X86] Simplify some code a little by removing a dulicate variable and combinining two if statements. NFCI

llvm-svn: 287443

The previous attempt didn't work. I assume LLVM_ATTRIBUTE_UNUSED isn't
available on that machine.

llvm-svn: 287442

Whether the variable is used or not depends on NDEBUG.

llvm-svn: 287440

Summary:
* ARM is omitted from this patch because this check appears to expose bugs in this target.
* Mips is omitted from this patch because this check either detects bugs or deliberate
  emission of instructions that don't satisfy their predicates. One deliberate
  use is the SYNC instruction where the version with an operand is correctly
  defined as requiring MIPS32 while the version without an operand is defined
  as an alias of 'SYNC 0' and requires MIPS2.
* X86 is omitted from this patch because it doesn't use the tablegen-erated
  MCCodeEmitter infrastructure.

Patches for ARM and Mips will follow.

Depends on D25617

Reviewers: tstellarAMD, jmolloy

Subscribers: wdng, jmolloy, aemerson, rengolin, arsenm, jyknight, nemanjai, nhaehnle, tstellarAMD, llvm-commits

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

llvm-svn: 287439

Summary: Depends on D25614

Reviewers: qcolombet

Subscribers: qcolombet, beanz, mgorny, llvm-commits

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

llvm-svn: 287438

llvm-lto2.cpp has the following include chain:

llvm/LTO/Caching.h
llvm/LTO/LTO.h
llvm/CodeGen/Analysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-lto2 needs to depend on intrinsics_gen.

llvm-svn: 287434

AnalysisWrappers.cpp has the following include chain:

llvm/Analysis/CallGraph.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means opt needs to depend on intrinsics_gen.

llvm-svn: 287433

llvm-nm.cpp has the following include chain:

llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-nm needs to depend on intrinsics_gen.

llvm-svn: 287432

llvm-link.cpp has the following include chain:

llvm/Bitcode/BitcodeWriter.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-link needs to depend on intrinsics_gen.

llvm-svn: 287431

llvm-extract.cpp has the following include chain:

llvm/Bitcode/BitcodeWriterPass.h
llvm/IR/PassManager.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-extract needs to depend on intrinsics_gen.

llvm-svn: 287430

llvm-dwp.cpp has the following include chain:

llvm/CodeGen/AsmPrinter.h
llvm/CodeGen/MachineFunctionPass.h
llvm/CodeGen/MachineFunction.h
llvm/CodeGen/MachineBasicBlock.h
llvm/CodeGen/MachineInstr.h
llvm/Analysis/AliasAnalysis.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-dwp needs to depend on intrinsics_gen.

llvm-svn: 287429

llvm-dis.cpp has the following include chain:

llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-dis needs to depend on intrinsics_gen.

llvm-svn: 287428

llvm-diff.cpp has the following include chain:

llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-diff needs to depend on intrinsics_gen.

llvm-svn: 287427

llvm-stress.cpp has the following include chain:

llvm/Analysis/CallGraphSCCPass.h
llvm/Analysis/CallGraph.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-stress needs to depend on intrinsics_gen.

llvm-svn: 287426

TestPasses.cpp has the following include chain:

llvm/IR/InstVisitor.h
llvm/IR/CallSite.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means bugpoint-passes needs to depend on intrinsics_gen.

llvm-svn: 287425

llvm-bcanalyzer.cpp has the following include chain:

llvm/Bitcode/BitcodeReader.h
llvm/IR/ModuleSummaryIndex.h
llvm/IR/Module.h
llvm/IR/Function.h
llvm/IR/Argument.h
llvm/IR/Attributes.h
llvm/IR/Attributes.gen

This means llvm-bcanalyzer needs to depend on intrinsics_gen.

llvm-svn: 287424