Summary:
I'm unable to find this number in the "AMD SOG for family 15h".
llvm-exegesis measures the latencies of these instructions as `2`,
which matches the latencies specified in "AMD SOG for family 15h".

However if we look at Agner, Microarchitecture, "AMD Bulldozer, Piledriver,
Steamroller and Excavator pipeline", "Data delay between different execution
domains", the int->ivec transfer is listed as `8`..`10`cy of additional latency.

Also, Agner's "Instruction tables", for Piledriver, lists their latencies as `12`,
which is consistent with `2cy` from exegesis / AMD SOG + `10cy` transfer delay.

Additional data point comes from the fact that Agner's "Instruction tables",
for Jaguar, lists their latencies as `8`; and "AMD SOG for family 16h" does
state the `+6cy` int->ivec delay, which is consistent with instr latency of `1` or `2`.

Reviewers: andreadb, RKSimon, craig.topper

Reviewed By: andreadb

Subscribers: gbedwell, courbet, llvm-commits

Tags: #llvm

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

llvm-svn: 352861

InlineCost's isInlineViable() is changed to return InlineResult
instead of bool. This provides messages for failure reasons and
allows to get more specific messages for cases where callsites
are not viable for inlining.

Reviewed By: xbolva00, anemet

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

llvm-svn: 352849

This was causing a build bot failure:
http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/15346/

llvm-svn: 352848

Prior to this change, there are a few tests called llvm-symbolizer* in
the DebugInfo test area. These really were testing either the DebugInfo
or Symbolizer library, rather than the llvm-symbolizer tool itself, so
this patch renames them to be clearer that they aren't explicitly tests
for llvm-symbolizer (such tests belong in test/tools/llvm-symbolizer).

This patch also reinstates the copying of a DWO file, removed previously
in r352752. The test needs this so that it could possibly fail.

Finally, some of the tests have been simplified slightly by removing
unnecessary switches and/or unused check-prefixes.

Reviewed by: dblaikie

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

llvm-svn: 352847

A while back, createStringError was added to provide easier construction
of StringError instances, especially with formatting options. Prior to
this patch, that the documentation only mentions the standard method of
using it. Since createStringError is slightly shorter to type, and also
provides the formatting options, this patch updates the Programmer's
Manual to use the new function in its examples, and to mention the
printf formatting options. It also fixes a small typo in one of the
examples and removes the unnecessary make_error_code call.

llvm-svn: 352846

Previously, LiveRegUnits was assuming that if a block has no successors
and does not return, then no registers are live at the end of it
(because the end of the block is unreachable). This was causing the
register scavenger to use callee-saved registers to materialise stack
frame addresses without saving them in the prologue. This would normally
be fine, because the end of the block is unreachable, but this is not
legal if the block ends by throwing a C++ exception. If this happens,
the scratch register will be modified, but its previous value won't be
preserved, so it doesn't get restored by the exception unwinder.

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

llvm-svn: 352844

These methods are very similar, patch merge them into one.

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

llvm-svn: 352840

Indices are checked as they are generated. No need to fill the whole array of indices.

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

llvm-svn: 352839

Looks like we still have a few bots that are sad. Let try to get them fixed!

llvm-svn: 352835

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

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

llvm-svn: 352834

This patch:
* Adds necessary RV64D codegen patterns
* Modifies CC_RISCV so it will properly handle f64 types (with soft float ABI)

Note that in general there is no reason to try to select fcvt.w[u].d rather than fcvt.l[u].d for i32 conversions because fptosi/fptoui produce poison if the input won't fit into the target type.

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

llvm-svn: 352833

For targets where i32 is not a legal type (e.g. 64-bit RISC-V),
LegalizeIntegerTypes must promote the integer operand of ISD::FPOWI. As this
is a signed value, this should be sign-extended.

This patch enables all tests in test/CodeGen/RISCVfloat-intrinsics.ll for
RV64, as prior to this patch that file couldn't be compiled for RV64 due to an
assertion when performing codegen for fpowi.

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

llvm-svn: 352832

Who knew...they're not built by default or as part of the tests.

llvm-svn: 352830

Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc
doesn't choke on it, hopefully.

Original Message:
The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352827

If we're optimizing for size, that overrides the subtarget
feature, so we would always produce 'inc' if we matched
this pattern.

llvm-svn: 352821

Another pattern exposed in D57516.

llvm-svn: 352820

[sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for fuzzing

llvm-svn: 352818

It should probably just be mandatory for getTgtMemIntrinsic to return
the alignment.

llvm-svn: 352817

A handful of bots are still breaking, either because I missed them in my audit,
they were offline, or something else. I'm contacting their authors, but I'll
revert for now and re-commit later.

llvm-svn: 352814

Summary:
The custom lowering introduced in rL352592 creates build_vector nodes
with negative i32 operands, but these operands did not meet the value
range constraints necessary to match build_vector nodes. This CL fixes
the issue by removing the unnecessary constraints.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish

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

llvm-svn: 352813

As was suggested when the policy originally went in.

llvm-svn: 352812

Summary:
The RFC on moving past C++11 got good traction:
  http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html

This patch therefore bumps the toolchain versions according to our policy:
  llvm.org/docs/DeveloperPolicy.html#toolchain

Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane

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

llvm-svn: 352811

Reviewers: jgravelle-google, sbc100

Subscribers: aheejin, llvm-commits

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

llvm-svn: 352810

This requires a little extra work due tothe fact i32 is not a legal type. When
call lowering happens post-legalisation (e.g. when an intrinsic was inserted
during legalisation). A bitcast from f32 to i32 can't be introduced. This is
similar to the challenges with RV32D. To handle this, we introduce
target-specific DAG nodes that perform bitcast+anyext for f32->i64 and
trunc+bitcast for i64->f32.

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

llvm-svn: 352807

Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits

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

llvm-svn: 352806

llvm-svn: 352805

llvm-svn: 352802

This reverts commit f47d6b38 (r352791).

Seems to run into compilation failures with GCC (but not clang, where
I tested it). Reverting while I investigate.

llvm-svn: 352800

llvm-svn: 352795

Summary: Moving special handling to MemorySSAUpdater in D57199.

Reviewers: gberry, george.burgess.iv

Subscribers: sanjoy, jlebar, Prazek, llvm-commits

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

llvm-svn: 352794

Summary: Also clean up some preexisting target feature code.

Reviewers: aheejin

Subscribers: dschuff, sbc100, jgravelle-google, hiraditya, sunfish, jfb

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

llvm-svn: 352793

This patch fixes pr39098.

For the attached test case, CombineZExtLogicopShiftLoad can optimize it to

t25: i64 = Constant<1099511627775>
t35: i64 = Constant<0>
  t0: ch = EntryToken
t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64
    t58: i64 = srl t57, Constant:i8<1>
  t60: i64 = and t58, Constant:i64<524287>
t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64

But later visitANDLike transforms it to

t25: i64 = Constant<1099511627775>
t35: i64 = Constant<0>
  t0: ch = EntryToken
t57: i64,ch = load<(load 4 from `i40* undef`, align 8), zext from i32> t0, undef:i64, undef:i64
      t61: i32 = truncate t57
    t63: i32 = srl t61, Constant:i8<1>
  t64: i32 = and t63, Constant:i32<524287>
t65: i64 = zero_extend t64
    t58: i64 = srl t57, Constant:i8<1>
  t60: i64 = and t58, Constant:i64<524287>
t29: ch = store<(store 5 into `i40* undef`, align 8), trunc to i40> t57:1, t60, undef:i64, undef:i64

And it triggers CombineZExtLogicopShiftLoad again, causes a dead loop.

Both forms should generate same instructions, CombineZExtLogicopShiftLoad generated IR looks cleaner. But it looks more difficult to prevent visitANDLike to do the transform, so I prevent CombineZExtLogicopShiftLoad to do the transform if the ZExt is free.

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

llvm-svn: 352792

The FunctionCallee type is effectively a {FunctionType*,Value*} pair,
and is a useful convenience to enable code to continue passing the
result of getOrInsertFunction() through to EmitCall, even once pointer
types lose their pointee-type.

Then:
- update the CallInst/InvokeInst instruction creation functions to
  take a Callee,
- modify getOrInsertFunction to return FunctionCallee, and
- update all callers appropriately.

One area of particular note is the change to the sanitizer
code. Previously, they had been casting the result of
`getOrInsertFunction` to a `Function*` via
`checkSanitizerInterfaceFunction`, and storing that. That would report
an error if someone had already inserted a function declaraction with
a mismatching signature.

However, in general, LLVM allows for such mismatches, as
`getOrInsertFunction` will automatically insert a bitcast if
needed. As part of this cleanup, cause the sanitizer code to do the
same. (It will call its functions using the expected signature,
however they may have been declared.)

Finally, in a small number of locations, callers of
`getOrInsertFunction` actually were expecting/requiring that a brand
new function was being created. In such cases, I've switched them to
Function::Create instead.

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

llvm-svn: 352791

CMake 3.6 introduced CMAKE_TRY_COMPILE_PLATFORM_VARIABLES, which solves
precisely the problem that necessitated init_user_prop, so we can switch
over whenever we bump our minimum CMake requirement.

llvm-svn: 352790

Summary:
EarlyCSE needs to optimize MemoryPhis after an access is removed and has
special handling for it. This should be handled by MemorySSA instead.
The default remains that MemoryPhis are *not* optimized after an access
is removed.

Reviewers: george.burgess.iv

Subscribers: sanjoy, jlebar, llvm-commits, Prazek

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

llvm-svn: 352787

Summary:
Like with X86, this allows better DAG-level alias analysis and
alignment inference for wrapped addresses.

Reviewers: jonpa, uweigand

Reviewed By: uweigand

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 352786

Summary:
Previously, llvm-nm would report symbols for .debug and .note sections as: '?' with an empty  section name:

```
00000000 ?
00000000 ?
...
```

With this patch the output more closely resembles GNU nm:
```
00000000 N .debug_abbrev
00000000 n .note.GNU-stack
...
```

This patch calls `getSectionName` for sections that belong to symbols of type `ELF::STT_SECTION`, which returns the name of the section from the section string table.

Reviewers: Bigcheese, davide, jhenderson

Reviewed By: davide, jhenderson

Subscribers: rupprecht, jhenderson, llvm-commits

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

llvm-svn: 352785

While dangling nodes will eventually be pruned when they are
considered, leaving them disables combines requiring single-use.

Reviewers: Carrot, spatel, craig.topper, RKSimon, efriedma

Subscribers: hiraditya, llvm-commits

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

llvm-svn: 352784

r zero scale SMULFIX, expand into MUL which produces better code for X86.

For vector arguments, expand into MUL if SMULFIX is provided with a zero scale.
Otherwise, expand into MULH[US] or [US]MUL_LOHI.

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

llvm-svn: 352783

This is causing a failure in chromium

llvm-svn: 352782