[InstCombine] fold udiv with common factor from muls with nuw

Unfortunately, sdiv isn't as simple because of UB due to overflow.

This fold is mentioned in PR38239:
https://bugs.llvm.org/show_bug.cgi?id=38239

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338059 91177308-0d34-0410-b5e6-96231b3b80d8

[RISCV] Add support for _interrupt attribute

- Save/restore only registers that are used.
This includes Callee saved registers and Caller saved registers
(arguments and temporaries) for integer and FP registers.
- If there is a call in the interrupt handler, save/restore all
Caller saved registers (arguments and temporaries) and all FP registers.
- Emit special return instructions depending on "interrupt"
attribute type.
Based on initial patch by Zhaoshi Zheng.

Reviewers: asb

Reviewed By: asb

Subscribers: rkruppe, the_o, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338047 91177308-0d34-0410-b5e6-96231b3b80d8

MacroFusion: Fix macro fusion with ExitSU failing in top-down scheduling

When fusing instructions A and B, we must add all predecessors of B as
predecessors of A to avoid instructions getting scheduling in between.

There is a special case involving ExitSU: Every other node must be
scheduled before it by design and we don't need to make this explicit in
the graph, however when fusing with a different node we need to schedule
every othere node before the fused node too and we need to make this
explicit now: This patch adds a dependency from the fused node to all
roots in the graph.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338046 91177308-0d34-0410-b5e6-96231b3b80d8

[DAGCombine] optimizeSetCCOfSignedTruncationCheck(): handle ule,ugt CondCodes.

Summary:
A follow-up for D49266 / rL337166.

At least one of these cases is more canonical,
so we really do have to handle it.
https://godbolt.org/g/pkzP3X
https://rise4fun.com/Alive/pQyhZZ

We won't get to these cases with I1 being -1,
as that will be constant-folded to true or false.

I'm also not sure we actually hit the 'ule' case,
but i think the worst think that could happen is that being dead code.

Reviewers: spatel, craig.topper, RKSimon, javed.absar, efriedma

Reviewed By: spatel

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338044 91177308-0d34-0410-b5e6-96231b3b80d8

[DEBUGINFO, NVPTX] Emit correct debug information for local variables.

Summary:
NVPTX target dos not use register-based frame information. Instead it
relies on the artificial local_depot that is used instead of the frame
and the data for variables must be emitted relatively to this
local_depot.

Reviewers: tra, jlebar, echristo

Subscribers: jholewinski, aprantl, JDevlieghere, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338039 91177308-0d34-0410-b5e6-96231b3b80d8

[InstCombine] add tests for udiv with common factor; NFC

This fold is mentioned in PR38239:
https://bugs.llvm.org/show_bug.cgi?id=38239

The general case probably belongs in -reassociate, but given that we do
basic reassociation optimizations similar to this in instcombine already,
we might as well be consistent within instcombine and handle this pattern?

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338038 91177308-0d34-0410-b5e6-96231b3b80d8

[DEBUGINFO, NVPTX] Set `DW_AT_frame_base` to `DW_OP_call_frame_cfa`.

Summary:
For NVPTX target the value of `DW_AT_frame_base` attribute must be set
to `DW_OP_call_frame_cfa`.

Reviewers: tra, jlebar, echristo

Subscribers: jholewinski, JDevlieghere, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338036 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r338027 to pacify build bot

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338035 91177308-0d34-0410-b5e6-96231b3b80d8

[ADT] Replace std::isprint by llvm::isPrint.

The standard library functions ::isprint/std::isprint have platform-
and locale-dependent behavior which makes LLVM's output less
predictable. In particular, regression tests my fail depending on the
implementation of these functions.

Implement llvm::isPrint in StringExtras.h with a standard behavior and
replace all uses of ::isprint/std::isprint by a call it llvm::isPrint.
The function is inlined and does not look up language settings so it
should perform better than the standard library's version.

Such a replacement has already been done for isdigit, isalpha, isxdigit
in r314883. gtest does the same in gtest-printers.cc using the following
justification:

    // Returns true if c is a printable ASCII character.  We test the
    // value of c directly instead of calling isprint(), which is buggy on
    // Windows Mobile.
    inline bool IsPrintableAscii(wchar_t c) {
      return 0x20 <= c && c <= 0x7E;
    }

Similar issues have also been encountered by Julia:
https://github.com/JuliaLang/julia/issues/7416

I noticed the problem myself when on Windows isprint('\t') started to
evaluate to true (see https://stackoverflow.com/questions/51435249) and
thus caused several unit tests to fail. The result of isprint doesn't
seem to be well-defined even for ASCII characters. Therefore I suggest
to replace isprint by a platform-independent version.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338034 91177308-0d34-0410-b5e6-96231b3b80d8

[UnJ] Common some code. NFC

Create a processHeaderPhiOperands for analysing the instructions
in the aft blocks that must be moved before the loop.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338033 91177308-0d34-0410-b5e6-96231b3b80d8

dwarfgen: Add support for generating the debug_str_offsets section, take 3

Previous version of this patch failed on darwin targets because of
different handling of cross-debug-section relocations. This fixes the
tests to emit the DW_AT_str_offsets_base attribute correctly in both
cases. Since doing this is a non-trivial amount of code, and I'm going
to need it in more than one test, I've added a helper function to the
dwarfgen DIE class to do it.

Original commit message follows:

The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.

This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
  DwarfStringPool, so I can generate the section header more easily from
  the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
  generate the DW_AT_str_offsets_base, which links a compile unit to the
  offset table.

I've also added a basic test for reading and writing DW_form_strx forms.

Reviewers: dblaikie, JDevlieghere, probinson

Subscribers: llvm-commits, aprantl

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338031 91177308-0d34-0410-b5e6-96231b3b80d8

[test] Disable dsymutil update test on windows

Apparently, the issue with dsymutil update functionality on Windows was
that Windows doesn't like dsymutil renaming files that have open handles
to them. This disables the new accelerator test and updates the comment
in the other two test.

We should be able to enable the tests again once we updated the
implementation to use TempFile::keep() to keep the temporary files in
MachOUtils.

A big thank you to Jeremy Morse from Sony for figuring this out and
bringing it to my attention.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338030 91177308-0d34-0410-b5e6-96231b3b80d8

Enable some pointer authentication instructions for aarch64 v8a targets

- Some of the v8.3 pointer authentication instruction inhabit the Hint space
- These instructions can be assembled to hint instructions which act as NOP instructions prior to v8.3
- This patch permits using the hint instructions for all v8a targets
- Also, correct the RETA{A,B} instructions to match the instruction attributes of RET (set isTerminator and isBarrier)

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338029 91177308-0d34-0410-b5e6-96231b3b80d8

Fix raw_fd_ostream::write_impl hang with large output

On Windows when raw_fd_ostream::write_impl calls write, a 32 bit input
is required for character count. As a variable with size_t is used for
this argument on x64 integral demotion occurs. In the case of large
files an infinite loop follows.

See PR37926.

This fix allows the output of files larger than previous int32 limit.

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

Patch by Owen Reynolds

Reviewed by: zturner

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338027 91177308-0d34-0410-b5e6-96231b3b80d8

dwarfgen: Don't create an AsmPrinter with an invalid ObjFile lowering

The AsmPrinter created in the tests contained an uninitialized
TargetLoweringObjectFile. Things mostly worked regardless, because we
used a separate instance of that class to specify sections to emit.

This rearanges the object construction order so that we can avoid
creating two lowering objects. Instead, we properly initialize the
object in the AsmPrinter, and have the DWARF generator store a pointer
to it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338026 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Sign extend i32 return values on MIPS64

Override getTypeForExtReturn so that functions returning
an i32 typed value have it sign extended on MIPS64.

Also provide patterns to get rid of unneeded sign extensions
for arithmetic instructions which implicitly sign extend
their results.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338019 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "[COFF] Use comdat shared constants for MinGW as well"

This reverts commit r337951.

While that kind of shared constant generally works fine in a MinGW
setting, it broke some cases of inline assembly that worked before:

$ cat const-asm.c
int MULH(int a, int b) {
    int rt, dummy;
    __asm__ (
        "imull %3"
        :"=d"(rt), "=a"(dummy)
        :"a"(a), "rm"(b)
    );
    return rt;
}
int func(int a) {
    return MULH(a, 1);
}
$ clang -target x86_64-win32-gnu -c const-asm.c -O2
const-asm.c:4:9: error: invalid variant '00000001'
        "imull %3"
        ^
<inline asm>:1:15: note: instantiated into assembly here
        imull __real@00000001(%rip)
                     ^

A similar error is produced for i686 as well. The same test with a
target of x86_64-win32-msvc or i686-win32-msvc works fine.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338018 91177308-0d34-0410-b5e6-96231b3b80d8

[x86/SLH] Extract the logic to trace predicate state through calls to
a helper function with a nice overview comment. NFC.

This is a preperatory refactoring to implementing another component of
mitigation here that was descibed in the design document but hadn't been
implemented yet.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338016 91177308-0d34-0410-b5e6-96231b3b80d8

[test] Do dsymutil update in place

Update the dSYM bundle in place when swapping out the accelerator
tables. This should unbreak the windows bot that have been failing with
an access denied.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338014 91177308-0d34-0410-b5e6-96231b3b80d8

Allow users of the GCOV API to extend the FileInfo class to implement custom output formats

Summary:
The GCOV API can be used to parse gcda/gcno files, but in order to implement custom output formats, users need to reimplement everything.
If the FileInfo members were protected instead of private, they'd be able to reuse the code.

Reviewers: bogner, davide, scott.smith

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338013 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64][NFC] Removed tab characters from test files.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338011 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch64] Armv8.2-A: add the crypto extensions

This adds MC support for the crypto instructions that were made optional
extensions in Armv8.2-A (AArch64 only).

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338010 91177308-0d34-0410-b5e6-96231b3b80d8

[ConstProp] Fix calls-math-finite.ll on FreeBSD

FreeBSD's log(3.0) is less precise than glibc and musl.
Let's forgive its rounding error of more than half an ulp.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338009 91177308-0d34-0410-b5e6-96231b3b80d8

[AsmParser] Fix preserve-comments-crlf.s on FreeBSD

--strip-trailing-cr is a diffutils option which is also available on
BSD-licensed diff introduced in FreeBSD 11.2, however, it has a bug
comparing files mixing \r and \r\n. Use -b (POSIX) instead.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338008 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Don't use CombineTo to skip adding new nodes to the DAGCombiner worklist in combineMul.

I'm not sure if this was trying to avoid optimizing the new nodes further or what. Or maybe to prevent a cycle if something tried to reform the multiply? But I don't think its a reliable way to do that. If the user of the expanded multiply is visited by the DAGCombiner after this conversion happens, the DAGCombiner will check its operands, see that they haven't been visited by the DAGCombiner before and it will then add the first node to the worklist. This process will repeat until all the new nodes are visited.

So this seems like an unreliable prevention at best. So this patch just returns the new nodes like any other combine. If this starts causing problems we can try to add target specific nodes or something to more directly prevent optimizations.

Now that we handle the combine normally, we can combine any negates the mul expansion creates into their users since those will be visited now.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338007 91177308-0d34-0410-b5e6-96231b3b80d8

[Docs] Update of Xray page

Update of supported oses.

Reviewers: dberris

Reviewed By: dberris

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@338003 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r337981: it breaks the debuginfo-tests

This commit caused a regression in the debuginfo-tests:

FAIL: debuginfo-tests :: apple-accel.cpp (40748 of 46595)

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337997 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Remove some unnecessary explicit calls to DCI.AddToWorkList.

These calls were making sure some newly created nodes were added to worklist, but the DAGCombiner has internal support for ensuring it has visited all nodes. Any time it visits a node it ensures the operands have been queued to be visited as well. This means if we only need to return the last new node. The DAGCombiner will take care of adding its inputs thus walking backwards through all the new nodes.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337996 91177308-0d34-0410-b5e6-96231b3b80d8

[Support] Introduce createStringError helper function

The function in question is copy-pasted lots of times in DWARF-related classes.
Thus it will make sense to place its implementation into the Support library.

Reviewed by: lhames

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337995 91177308-0d34-0410-b5e6-96231b3b80d8

[GlobalISel] Fall back to SDISel for swifterror/swiftself attributes.

We don't currently support these, fall back until we do.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337994 91177308-0d34-0410-b5e6-96231b3b80d8

[DWARF v5] Don't report an error when the .debug_rnglists section is empty or non-existent. Fixes PR38297.

Reviewer: JDevlieghere

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337993 91177308-0d34-0410-b5e6-96231b3b80d8

[LoadStoreVectorizer] Use const reference

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337992 91177308-0d34-0410-b5e6-96231b3b80d8

RegUsageInfo: Cleanup; NFC

- Remove unnecessary anchor function
- Remove unnecessary override of getAnalysisUsage
- Use reference instead of pointers where things cannot be nullptr
- Use ArrayRef instead of std::vector where possible

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337989 91177308-0d34-0410-b5e6-96231b3b80d8

CodeGen.cpp: Sort initializers; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337988 91177308-0d34-0410-b5e6-96231b3b80d8

InitializePasses: Sort declarations; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337987 91177308-0d34-0410-b5e6-96231b3b80d8

CodeGen: Cleanup regmask construction; NFC

- Avoid duplication of regmask size calculation.
- Simplify allocateRegisterMask() call.
- Rename allocateRegisterMask() to allocateRegMask() to be consistent
  with naming in MachineOperand.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337986 91177308-0d34-0410-b5e6-96231b3b80d8

[MCA] Avoid an InstrDesc copy in mca::LSUnit::reserve.

Summary:
InstrDesc contains 4 vectors (as well as some other data), so it's
expensive to copy.

Authored By: orodley

Reviewers: andreadb, mattd, dberris

Reviewed By: mattd, dberris

Subscribers: dberris, gbedwell, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337985 91177308-0d34-0410-b5e6-96231b3b80d8

[DWARF v5] Don't emit multiple DW_AT_rnglists_base attributes. Some refactoring of
range lists emissions and added test cases.

Reviewer: dblaikie

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337981 91177308-0d34-0410-b5e6-96231b3b80d8

[dsymutil] Add support for generating DWARF5 accelerator tables.

This patch add support for emitting DWARF5 accelerator tables
(.debug_names) from dsymutil. Just as with the Apple style accelerator
tables, it's possible to update existing dSYMs. This patch includes a
test that show how you can convert back and forth between the two types.

If no kind of table is specified, dsymutil will default to generating
Apple-style accelerator tables whenever it finds those in its input. The
same is true when there are no accelerator tables at all. Finally, in
the remaining case, where there's at least one DWARF v5 table and no
Apple ones, the output will contains a DWARF accelerator tables
(.debug_names).

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337980 91177308-0d34-0410-b5e6-96231b3b80d8

bpf: new option -bpf-expand-memcpy-in-order to expand memcpy in order

Some BPF JIT backends would want to optimize memcpy in their own
architecture specific way.

However, at the moment, there is no way for JIT backends to see memcpy
semantics in a reliable way. This is due to LLVM BPF backend is expanding
memcpy into load/store sequences and could possibly schedule them apart from
each other further. So, BPF JIT backends inside kernel can't reliably
recognize memcpy semantics by peephole BPF sequence.

This patch introduce new intrinsic expand infrastructure to memcpy.

To get stable in-order load/store sequence from memcpy, we first lower
memcpy into BPF::MEMCPY node which then expanded into in-order load/store
sequences in expandPostRAPseudo pass which will happen after instruction
scheduling. By this way, kernel JIT backends could reliably recognize
memcpy through scanning BPF sequence.

This new memcpy expand infrastructure is gated by a new option:

  -bpf-expand-memcpy-in-order

Acked-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: Jiong Wang <jiong.wang@netronome.com>
Signed-off-by: Yonghong Song <yhs@fb.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337977 91177308-0d34-0410-b5e6-96231b3b80d8

[GlobalMerge] Handle llvm.compiler.used correctly.

Reuse the handling for llvm.used, and don't transform such globals.

Fixes a failure on the asan buildbot caused by my previous commit.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337973 91177308-0d34-0410-b5e6-96231b3b80d8

[SelectionDAG] try to convert funnel shift directly to rotate if legal

If the DAGCombiner's rotate matching was working as expected,
I don't think we'd see any test diffs here.

This sidesteps the issue of custom lowering for rotates raised in PR38243:
https://bugs.llvm.org/show_bug.cgi?id=38243
...by only dealing with legal operations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337966 91177308-0d34-0410-b5e6-96231b3b80d8

[LSV] Look through selects for consecutive addresses

In some cases LSV sees (load/store _ (select _ <pointer expression>
<pointer expression>)) patterns in input IR, often due to sinking and
other forms of CFG simplification, sometimes interspersed with
bitcasts and all-constant-indices GEPs. With this
patch`areConsecutivePointers` method would attempt to handle select
instructions. This leads to an increased number of successful
vectorizations.

Technically, select instructions could appear in index arithmetic as
well, however, we don't see those in our test suites / benchmarks.
Also, there is a lot more freedom in IR shapes computing integral
indices in general than in what's common in pointer computations, and
it appears that it's quite unreliable to do anything short of making
select instructions first class citizens of Scalar Evolution, which
for the purposes of this patch is most definitely an overkill.

Reviewed By: rampitec

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337965 91177308-0d34-0410-b5e6-96231b3b80d8

[AArch, PowerPC] add more tests for legal rotate ops; NFC

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337964 91177308-0d34-0410-b5e6-96231b3b80d8

[GlobalMerge] Allow merging globals with arbitrary alignment.

Instead of depending on implicit padding from the structure layout code,
use a packed struct and emit the padding explicitly.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337961 91177308-0d34-0410-b5e6-96231b3b80d8

Revert r337904: [IPSCCP] Use PredicateInfo to propagate facts from cmp instructions.

I suspect it is causing the clang-stage2-Rthinlto failures.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337956 91177308-0d34-0410-b5e6-96231b3b80d8

Add missing 'override', fixing compilation with some compilers since SVN r337950

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337952 91177308-0d34-0410-b5e6-96231b3b80d8

[COFF] Use comdat shared constants for MinGW as well

GNU binutils tools have no problems with this kind of shared constants,
provided that we actually hook it up completely in AsmPrinter and
produce a global symbol.

This effectively reverts SVN r335918 by hooking the rest of it up
properly.

This feature was implemented originally in SVN r213006, with no reason
for why it can't be used for MinGW other than the fact that GCC doesn't
do it while MSVC does.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337951 91177308-0d34-0410-b5e6-96231b3b80d8

[COFF] Hoist constant pool handling from X86AsmPrinter into AsmPrinter

In SVN r334523, the first half of comdat constant pool handling was
hoisted from X86WindowsTargetObjectFile (which despite the name only
was used for msvc targets) into the arch independent
TargetLoweringObjectFileCOFF, but the other half of the handling was
left behind in X86AsmPrinter::GetCPISymbol.

With only half of the handling in place, inconsistent comdat
sections/symbols are created, causing issues with both GNU binutils
(avoided for X86 in SVN r335918) and with the MS linker, which
would complain like this:

fatal error LNK1143: invalid or corrupt file: no symbol for COMDAT section 0x4

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337950 91177308-0d34-0410-b5e6-96231b3b80d8

[LangRef] Clarify undefined behavior for function attributes.

Violating the invariants specified by attributes is undefined behavior.
Maybe we could use poison instead for some of the parameter attributes,
but I don't think it's worthwhile.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337947 91177308-0d34-0410-b5e6-96231b3b80d8

[ARM] Prefer lsls+lsrs over lsls+ands or lsrs+ands in Thumb1.

Saves materializing the immediate for the "ands".

Corresponding patterns exist for lsrs+lsls, but that seems less common
in practice.

Now implemented as a DAGCombine.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337945 91177308-0d34-0410-b5e6-96231b3b80d8

[SCEV] Add [zs]ext{C,+,x} -> (D + [zs]ext{C-D,+,x})<nuw><nsw> transform

as well as sext(C + x + ...) -> (D + sext(C-D + x + ...))<nuw><nsw>
similar to the equivalent transformation for zext's

if the top level addition in (D + (C-D + x * n)) could be proven to
not wrap, where the choice of D also maximizes the number of trailing
zeroes of (C-D + x * n), ensuring homogeneous behaviour of the
transformation and better canonicalization of such AddRec's

(indeed, there are 2^(2w) different expressions in `B1 + ext(B2 + Y)` form for
the same Y, but only 2^(2w - k) different expressions in the resulting `B3 +
ext((B4 * 2^k) + Y)` form, where w is the bit width of the integral type)

This patch generalizes sext(C1 + C2*X) --> sext(C1) + sext(C2*X) and
sext{C1,+,C2} --> sext(C1) + sext{0,+,C2} transformations added in
r209568 relaxing the requirements the following way:

1. C2 doesn't have to be a power of 2, it's enough if it's divisible by 2
 a sufficient number of times;
2. C1 doesn't have to be less than C2, instead of extracting the entire
  C1 we can split it into 2 terms: (00...0XXX + YY...Y000), keep the
  second one that may cause wrapping within the extension operator, and
  move the first one that doesn't affect wrapping out of the extension
  operator, enabling further simplifications;
3. C1 and C2 don't have to be positive, splitting C1 like shown above
 produces a sum that is guaranteed to not wrap, signed or unsigned;
4. in AddExpr case there could be more than 2 terms, and in case of
  AddExpr the 2nd and following terms and in case of AddRecExpr the
  Step component don't have to be in the C2*X form or constant
  (respectively), they just need to have enough trailing zeros,
  which in turn could be guaranteed by means other than arithmetics,
  e.g. by a pointer alignment;
5. the extension operator doesn't have to be a sext, the same
  transformation works and profitable for zext's as well.

Apparently, optimizations like SLPVectorizer currently fail to
vectorize even rather trivial cases like the following:

 double bar(double *a, unsigned n) {
   double x = 0.0;
   double y = 0.0;
   for (unsigned i = 0; i < n; i += 2) {
     x += a[i];
     y += a[i + 1];
   }
   return x * y;
 }

If compiled with `clang -std=c11 -Wpedantic -Wall -O3 main.c -S -o - -emit-llvm`
(!{!"clang version 7.0.0 (trunk 337339) (llvm/trunk 337344)"})

it produces scalar code with the loop not unrolled with the unsigned `n` and
`i` (like shown above), but vectorized and unrolled loop with signed `n` and
`i`. With the changes made in this commit the unsigned version will be
vectorized (though not unrolled for unclear reasons).

How it all works:

Let say we have an AddExpr that looks like (C + x + y + ...), where C
is a constant and x, y, ... are arbitrary SCEVs. Let's compute the
minimum number of trailing zeroes guaranteed of that sum w/o the
constant term: (x + y + ...). If, for example, those terms look like
follows:

        i
XXXX...X000
YYYY...YY00
   ...
ZZZZ...0000

then the rightmost non-guaranteed-zero bit (a potential one at i-th
position above) can change the bits of the sum to the left (and at
i-th position itself), but it can not possibly change the bits to the
right. So we can compute the number of trailing zeroes by taking a
minimum between the numbers of trailing zeroes of the terms.

Now let's say that our original sum with the constant is effectively
just C + X, where X = x + y + .... Let's also say that we've got 2
guaranteed trailing zeros for X:

         j
CCCC...CCCC
XXXX...XX00  // this is X = (x + y + ...)

Any bit of C to the left of j may in the end cause the C + X sum to
wrap, but the rightmost 2 bits of C (at positions j and j - 1) do not
affect wrapping in any way. If the upper bits cause a wrap, it will be
a wrap regardless of the values of the 2 least significant bits of C.
If the upper bits do not cause a wrap, it won't be a wrap regardless
of the values of the 2 bits on the right (again).

So let's split C to 2 constants like follows:

0000...00CC  = D
CCCC...CC00  = (C - D)

and represent the whole sum as D + (C - D + X). The second term of
this new sum looks like this:

CCCC...CC00
XXXX...XX00
-----------  // let's add them up
YYYY...YY00

The sum above (let's call it Y)) may or may not wrap, we don't know,
so we need to keep it under a sext/zext. Adding D to that sum though
will never wrap, signed or unsigned, if performed on the original bit
width or the extended one, because all that that final add does is
setting the 2 least significant bits of Y to the bits of D:

YYYY...YY00 = Y
0000...00CC = D
-----------  <nuw><nsw>
YYYY...YYCC

Which means we can safely move that D out of the sext or zext and
claim that the top-level sum neither sign wraps nor unsigned wraps.

Let's run an example, let's say we're working in i8's and the original
expression (zext's or sext's operand) is 21 + 12x + 8y. So it goes
like this:

0001 0101  // 21
XXXX XX00  // 12x
YYYY Y000  // 8y

0001 0101  // 21
ZZZZ ZZ00  // 12x + 8y

0000 0001  // D
0001 0100  // 21 - D = 20
ZZZZ ZZ00  // 12x + 8y

0000 0001  // D
WWWW WW00  // 21 - D + 12x + 8y = 20 + 12x + 8y

therefore zext(21 + 12x + 8y) = (1 + zext(20 + 12x + 8y))<nuw><nsw>

This approach could be improved if we move away from using trailing
zeroes and use KnownBits instead. For instance, with KnownBits we could
have the following picture:

    i
10 1110...0011  // this is C
XX X1XX...XX00  // this is X = (x + y + ...)

Notice that some of the bits of X are known ones, also notice that
known bits of X are interspersed with unknown bits and not grouped on
the rigth or left.

We can see at the position i that C(i) and X(i) are both known ones,
therefore the (i + 1)th carry bit is guaranteed to be 1 regardless of
the bits of C to the right of i. For instance, the C(i - 1) bit only
affects the bits of the sum at positions i - 1 and i, and does not
influence if the sum is going to wrap or not. Therefore we could split
the constant C the following way:

    i
00 0010...0011  = D
10 1100...0000  = (C - D)

Let's compute the KnownBits of (C - D) + X:

XX1 1            = carry bit, blanks stand for known zeroes
 10 1100...0000  = (C - D)
 XX X1XX...XX00  = X
--- -----------
 XX X0XX...XX00

Will this add wrap or not essentially depends on bits of X. Adding D
to this sum, however, is guaranteed to not to wrap:

0    X
 00 0010...0011  = D
 sX X0XX...XX00  = (C - D) + X
--- -----------
 sX XXXX   XX11

As could be seen above, adding D preserves the sign bit of (C - D) +
X, if any, and has a guaranteed 0 carry out, as expected.

The more bits of (C - D) we constrain, the better the transformations
introduced here canonicalize expressions as it leaves less freedom to
what values the constant part of ((C - D) + x + y + ...) can take.

Reviewed By: mzolotukhin, efriedma

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337943 91177308-0d34-0410-b5e6-96231b3b80d8

[windows] Don't inline fieldFromInstruction on Windows

Summary:
The VS compiler (on Windows) has a bug which results in fieldFromInstruction being optimized out in some circumstances. This only happens in *release no debug info* builds that have assertions *turned off* - in all other situations the function is not inlined, so the functionality is correct. All of the bots have assertions turned on, so this path is not regularly tested. The workaround is to not inline the function on Windows - if the bug is fixed in a later release of the VS compiler, the noinline specification can be removed.

The test that consistently reproduces this is Lanai v11.txt test.

Reviewers: asmith, labath, zturner

Subscribers: dblaikie, stella.stamenova, aprantl, JDevlieghere, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337942 91177308-0d34-0410-b5e6-96231b3b80d8

Add an option to specify the name of
an function whose CFG is to be viewed/printed.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337940 91177308-0d34-0410-b5e6-96231b3b80d8

Fix corruption of result number in LegalizeVectorOps.cpp

When VectorLegalizer::LegalizeOp creates a new SDValue after iterating
over its arguments, we need to refer to the same result number of the
new node that the original value used.

Reviewed by: cameron.mcinally

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337939 91177308-0d34-0410-b5e6-96231b3b80d8

[AMDGPU] Use AssumptionCacheTracker in the divrem32 expansion

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337938 91177308-0d34-0410-b5e6-96231b3b80d8

Fix llvm::ComputeNumSignBits with some operations and llvm.assume

Currently ComputeNumSignBits does early exit while processing some
of the operations (add, sub, mul, and select). This prevents the
function from using AssumptionCacheTracker if passed.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337936 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "dwarfgen: Add support for generating the debug_str_offsets section, take 2"

This reverts commit r337933. The build error is fixed but the test now
fails on the darwin buildbots. Investigating...

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337935 91177308-0d34-0410-b5e6-96231b3b80d8

[Hexagon] Properly scale bit index when extracting elements from vNi1

For example v = <2 x i1> is represented as bbbbaaaa in a predicate register,
where b = v[1], a = v[0]. Extracting v[1] is equivalent to extracting bit 4
from the predicate register.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337934 91177308-0d34-0410-b5e6-96231b3b80d8

dwarfgen: Add support for generating the debug_str_offsets section, take 2

This recommits r337910 after fixing an "ambiguous call to addAttribute"
error with some compilers (gcc circa 4.9 and MSVC). It seems that these
compilers will consider a "false -> pointer" conversion during overload
resolution. This creates ambiguity because one I added an overload which
takes a MCExpr * as an argument.

I fix this by making the new overload take MCExpr&, which avoids the
conversion. It also documents the fact that we expect a valid MCExpr
object.

Original commit message follows:

The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.

This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
  DwarfStringPool, so I can generate the section header more easily from
  the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
  generate the DW_AT_str_offsets_base, which links a compile unit to the
  offset table.

I've also added a basic test for reading and writing DW_form_strx forms.

Reviewers: dblaikie, JDevlieghere, probinson

Subscribers: llvm-commits, aprantl

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337933 91177308-0d34-0410-b5e6-96231b3b80d8

Move JIT listener C binding fallbackks to ExecutionEngineBindings.cpp.

Initially, in https://reviews.llvm.org/D44890, I had these defined as
empty functions inside the header when the respective event listener
was not built in. As done in that commit, that wasn't correct, because
it was a ODR violation.  Krasimir hot-fixed that in r333265, but that
wasn't quite right either, because it'd lead to the symbol not being
available.

Instead just move the fallbacksto ExecutionEngineBindings.cpp. Could
define them as static inlines in the header too, but I don't think it
matters.

Reviewers: whitequark

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337930 91177308-0d34-0410-b5e6-96231b3b80d8

Revert "dwarfgen: Add support for generating the debug_str_offsets section"

This reverts commit r337910 as it's generating "ambiguous call to
addAttribute" errors on some bots.

Will resubmit once I get a chance to look into the problem.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337924 91177308-0d34-0410-b5e6-96231b3b80d8

[MIPS GlobalISel] Lower pointer arguments

Add support for lowering pointer arguments.
Changing type from pointer to integer is already done in
MipsTargetLowering::getRegisterTypeForCallingConv.

Patch by Petar Avramovic.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337912 91177308-0d34-0410-b5e6-96231b3b80d8

dwarfgen: Add support for generating the debug_str_offsets section

Summary:
The motivation for this is D49493, where we'd like to test details of
debug_str_offsets behavior which is difficult to trigger from a
traditional test.

This adds the plubming necessary for dwarfgen to generate this section.
The more interesting changes are:
- I've moved emitStringOffsetsTableHeader function from DwarfFile to
  DwarfStringPool, so I can generate the section header more easily from
  the unit test.
- added a new addAttribute overload taking an MCExpr*. This is used to
  generate the DW_AT_str_offsets_base, which links a compile unit to the
  offset table.

I've also added a basic test for reading and writing DW_form_strx forms.

Reviewers: dblaikie, JDevlieghere, probinson

Subscribers: llvm-commits, aprantl

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337910 91177308-0d34-0410-b5e6-96231b3b80d8

[SystemZ]  Use tablegen loops in SchedModels

NFC changes to make scheduler TableGen files more readable, by using loops
instead of a lot of similar defs with just e.g. a latency value that changes.

https://reviews.llvm.org/D49598
Review: Ulrich Weigand, Javed Abshar

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337909 91177308-0d34-0410-b5e6-96231b3b80d8

Recommit r333268: [IPSCCP] Use PredicateInfo to propagate facts from cmp instructions.

r337828 resolves a PredicateInfo issue with unnamed types.

Original message:
This patch updates IPSCCP to use PredicateInfo to propagate
facts to true branches predicated by EQ and to false branches
predicated by NE.

As a follow up, we should be able to extend it to also propagate additional
facts about nonnull.

Reviewers: davide, mssimpso, dberlin, efriedma

Reviewed By: davide, dberlin

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337904 91177308-0d34-0410-b5e6-96231b3b80d8

Fix PR34170: Crash on inline asm with 64bit output in 32bit GPR

Add support for inline assembly with output operand that do not
naturally go in the register class it is constrained to (eg. double in a
32-bit GPR as in the PR).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337903 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-objdump] Add dynamic section printing to private-headers option

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337902 91177308-0d34-0410-b5e6-96231b3b80d8

[llvm-readobj] Generic hex-dump option

Helpers are available to make this option file format independant. This
patch adds the feature for Wasm file format. It doesn't change the
behavior of the other file format handling.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337896 91177308-0d34-0410-b5e6-96231b3b80d8

[x86/SLH] Sink the return hardening into the main block-walk + hardening
code.

This consolidates all our hardening calls, and simplifies the code
a bit. It seems much more clear to handle all of these together.

No functionality changed here.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337895 91177308-0d34-0410-b5e6-96231b3b80d8

[x86/SLH] Improve name and comments for the main hardening function.

This function actually does two things: it traces the predicate state
through each of the basic blocks in the function (as that isn't directly
handled by the SSA updater) *and* it hardens everything necessary in the
block as it goes. These need to be done together so that we have the
currently active predicate state to use at each point of the hardening.

However, this also made obvious that the flag to disable actual
hardening of loads was flawed -- it also disabled tracing the predicate
state across function calls within the body of each block. So this patch
sinks this debugging flag test to correctly guard just the hardening of
loads.

Unless load hardening was disabled, no functionality should change with
tis patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337894 91177308-0d34-0410-b5e6-96231b3b80d8

[mips] Replace custom parsing logic for data directives by the `addAliasForDirective`

The target independent AsmParser doesn't recognise .hword, .word, .dword
which are required for Mips. Currently MipsAsmParser recognises these
through dispatch to MipsAsmParser::parseDataDirective. This contains
equivalent logic to AsmParser::parseDirectiveValue. This patch allows
reuse of AsmParser::parseDirectiveValue by making use of
addAliasForDirective to support .hword, .word and .dword.

Original patch provided by Alex Bradbury at D47001 was modified to fix
handling of microMIPS symbols. The `AsmParser::parseDirectiveValue`
calls either `EmitIntValue` or `EmitValue`. In this patch we override
`EmitIntValue` in the `MipsELFStreamer` to clear a pending set of
microMIPS symbols.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337893 91177308-0d34-0410-b5e6-96231b3b80d8

[Dominators] Assert if there is modification to DelBB while it is awaiting deletion

Summary:
Previously, passes use
```
DomTreeUpdater DTU(DT, DomTreeUpdater::UpdateStrategy::Lazy);
DTU.deleteBB(DelBB);
```
to delete a BasicBlock.
But passes which don't have the ability to update DomTree (e.g. tailcallelim, simplifyCFG) cannot recognize a DelBB awaiting deletion and will continue to process this DelBB.
This is a simple approach to notify devs of passes which may use DTU in the future to deal with deleted BasicBlocks under Lazy Strategy correctly.

Reviewers: kuhar, brzycki, dmgreen

Reviewed By: kuhar

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337891 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Use X86ISD::MUL_IMM instead of ISD::MUL for multiply we intend to be selected to LEA.

This prevents other combines from possibly disturbing it.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337890 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Autogenerate complete checks and fix a failure introduced in r337875.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337889 91177308-0d34-0410-b5e6-96231b3b80d8

[RegisterBankInfo] Ignore InstrMappings that create impossible to repair operands

Summary:
This is a follow-up to r303043.  In computeMapping(), we need to disqualify an
InstrMapping if it would be impossible to repair one of the registers in the
instruction to match the mapping.

This change is needed in order to be able to define an instruction
mapping for G_SELECT for the AMDGPU target and will be tested
by test/CodeGen/AMDGPU/GlobalISel/regbankselect-select.mir

Reviewers: ab, qcolombet, t.p.northover, dsanders

Reviewed By: qcolombet

Subscribers: tpr, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337882 91177308-0d34-0410-b5e6-96231b3b80d8

[profile] Support profiling runtime on Fuchsia

This ports the profiling runtime on Fuchsia and enables the
instrumentation. Unlike on other platforms, Fuchsia doesn't use
files to dump the instrumentation data since on Fuchsia, filesystem
may not be accessible to the instrumented process. We instead use
the data sink to pass the profiling data to the system the same
sanitizer runtimes do.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337881 91177308-0d34-0410-b5e6-96231b3b80d8

[x86/SLH] Teach the x86 speculative load hardening pass to harden
against v1.2 BCBS attacks directly.

Attacks using spectre v1.2 (a subset of BCBS) are described in the paper
here:
https://people.csail.mit.edu/vlk/spectre11.pdf

The core idea is to speculatively store over the address in a vtable,
jumptable, or other target of indirect control flow that will be
subsequently loaded. Speculative execution after such a store can
forward the stored value to subsequent loads, and if called or jumped
to, the speculative execution will be steered to this potentially
attacker controlled address.

Up until now, this could be mitigated by enableing retpolines. However,
that is a relatively expensive technique to mitigate this particular
flavor. Especially because in most cases SLH will have already mitigated
this. To fully mitigate this with SLH, we need to do two core things:
1) Unfold loads from calls and jumps, allowing the loads to be post-load
   hardened.
2) Force hardening of incoming registers even if we didn't end up
   needing to harden the load itself.

The reason we need to do these two things is because hardening calls and
jumps from this particular variant is importantly different from
hardening against leak of secret data. Because the "bad" data here isn't
a secret, but in fact speculatively stored by the attacker, it may be
loaded from any address, regardless of whether it is read-only memory,
mapped memory, or a "hardened" address. The only 100% effective way to
harden these instructions is to harden the their operand itself. But to
the extent possible, we'd like to take advantage of all the other
hardening going on, we just need a fallback in case none of that
happened to cover the particular input to the control transfer
instruction.

For users of SLH, currently they are paing 2% to 6% performance overhead
for retpolines, but this mechanism is expected to be substantially
cheaper. However, it is worth reminding folks that this does not
mitigate all of the things retpolines do -- most notably, variant #2 is
not in *any way* mitigated by this technique. So users of SLH may still
want to enable retpolines, and the implementation is carefuly designed to
gracefully leverage retpolines to avoid the need for further hardening
here when they are enabled.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337878 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Use a shift plus an lea for multiplying by a constant that is a power of 2 plus 2/4/8.

The LEA allows us to combine an add and the multiply by 2/4/8 together so we just need a shift for the larger power of 2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337875 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Expand mul by pow2 + 2 using a shift and two adds similar to what we do for pow2 - 2.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337874 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Use a two lea sequence for multiply by 37, 41, and 73.

These fit a pattern used by 11, 21, and 19.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337871 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add test cases for multiply by 37, 41, and 73.

These can all be handled with 2 LEAs similar to what we do for 11, 19, 21.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337870 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Change multiply by 26 to use two multiplies by 5 and an add instead of multiply by 3 and 9 and a subtract.

Same number of operations, but ending in an add is friendlier due to it being commutable.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337869 91177308-0d34-0410-b5e6-96231b3b80d8

[LV] Fix for PR38110, LV encountered llvm_unreachable()

Summary: truncateToMinimalBitWidths() doesn't handle all Instructions and the worst case is compiler crash via llvm_unreachable(). Fix is to add a case to handle PHINode and changed the worst case to NO-OP (from compiler crash).

Reviewers: sbaranga, mssimpso, hsaito

Reviewed By: hsaito

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337861 91177308-0d34-0410-b5e6-96231b3b80d8

[SCEV] Add zext(C + x + ...) -> D + zext(C-D + x + ...)<nuw><nsw> transform

if the top level addition in (D + (C-D + x + ...)) could be proven to
not wrap, where the choice of D also maximizes the number of trailing
zeroes of (C-D + x + ...), ensuring homogeneous behaviour of the
transformation and better canonicalization of such expressions.

This enables better canonicalization of expressions like

  1 + zext(5 + 20 * %x + 24 * %y)  and
      zext(6 + 20 * %x + 24 * %y)

which get both transformed to

  2 + zext(4 + 20 * %x + 24 * %y)

This pattern is common in address arithmetics and the transformation
makes it easier for passes like LoadStoreVectorizer to prove that 2 or
more memory accesses are consecutive and optimize (vectorize) them.

Reviewed By: mzolotukhin

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337859 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] When expanding a multiply by a negative of one less than a power of 2, like 31, don't generate a negate of a subtract that we'll never optimize.

We generated a subtract for the power of 2 minus one then negated the result. The negate can be optimized away by swapping the subtract operands, but DAG combine doesn't know how to do that and we don't add any of the new nodes to the worklist anyway.

This patch makes use explicitly emit the swapped subtract.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337858 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Generalize the multiply by 30 lowering to generic multipy by power 2 minus 2.

Use a left shift and 2 subtracts like we do for 30. Move this out from behind the slow lea check since it doesn't even use an LEA.

Use this for multiply by 14 as well.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337856 91177308-0d34-0410-b5e6-96231b3b80d8

[WebAssembly] Add tests for weaker memory consistency orderings

Summary:
Currently all wasm atomic memory access instructions are sequentially
consistent, so even if LLVM IR specifies weaker orderings than that, we
should upgrade them to sequential ordering and treat them in the same
way.

Reviewers: dschuff

Subscribers: sbc100, jgravelle-google, sunfish, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337854 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Change multiply by 19 to use (9 * X) * 2 + X instead of (5 * X) * 4 - 1.

The new lowering can be done in 2 LEAs. The old code took 1 LEA, 1 shift, and 1 sub.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337851 91177308-0d34-0410-b5e6-96231b3b80d8

[MachineOutliner][NFC] Move outlined function remark into its own function

This pulls the OutlinedFunction remark out into its own function to make
the code a bit easier to read.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337849 91177308-0d34-0410-b5e6-96231b3b80d8

[MachineOutliner][NFC] Move target frame info into OutlinedFunction

Just some gardening here.

Similar to how we moved call information into Candidates, this moves outlined
frame information into OutlinedFunction. This allows us to remove
TargetCostInfo entirely.

Anywhere where we returned a TargetCostInfo struct, we now return an
OutlinedFunction. This establishes OutlinedFunctions as more of a general
repeated sequence, and Candidates as occurrences of those repeated sequences.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337848 91177308-0d34-0410-b5e6-96231b3b80d8

Put "built-in" function definitions in global Used list, for LTO. (fix bug 34169)

When building with LTO, builtin functions that are defined but whose calls have not been inserted yet, get internalized. The Global Dead Code Elimination phase in the new LTO implementation then removes these function definitions. Later optimizations add calls to those functions, and the linker then dies complaining that there are no definitions. This CL fixes the new LTO implementation to check if a function is builtin, and if so, to not internalize (and later DCE) the function. As part of this fix I needed to move the RuntimeLibcalls.{def,h} files from the CodeGen subidrectory to the IR subdirectory. I have updated all the files that accessed those two files to access their new location.

Fixes PR34169

Patch by Caroline Tice!

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337847 91177308-0d34-0410-b5e6-96231b3b80d8

[x86] Teach the x86 backend that it can fold between TCRETURNm* and TCRETURNr* and fix latent bugs with register class updates.

Summary:
Enabling this fully exposes a latent bug in the instruction folding: we
never update the register constraints for the register operands when
fusing a load into another operation. The fused form could, in theory,
have different register constraints on its operands. And in fact,
TCRETURNm* needs its memory operands to use tailcall compatible
registers.

I've updated the folding code to re-constrain all the registers after
they are mapped onto their new instruction.

However, we still can't enable folding in the general case from
TCRETURNr* to TCRETURNm* because doing so may require more registers to
be available during the tail call. If the call itself uses all but one
register, and the folded load would require both a base and index
register, there will not be enough registers to allocate the tail call.

It would be better, IMO, to teach the register allocator to *unfold*
TCRETURNm* when it runs out of registers (or specifically check the
number of registers available during the TCRETURNr*) but I'm not going
to try and solve that for now. Instead, I've just blocked the forward
folding from r -> m, leaving LLVM free to unfold from m -> r as that
doesn't introduce new register pressure constraints.

The down side is that I don't have anything that will directly exercise
this. Instead, I will be immediately using this it my SLH patch. =/

Still worse, without allowing the TCRETURNr* -> TCRETURNm* fold, I don't
have any tests that demonstrate the failure to update the memory operand
register constraints. This patch still seems correct, but I'm nervous
about the degree of testing due to this.

Suggestions?

Reviewers: craig.topper

Subscribers: sanjoy, mcrosier, hiraditya, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337845 91177308-0d34-0410-b5e6-96231b3b80d8

[Inliner] Teach inliner to merge 'min-legal-vector-width' function attribute

When we inline a function with a min-legal-vector-width attribute we need to make sure the caller also ends up with at least that vector width.

This patch is necessary to make always_inline functions like intrinsics propagate their min-legal-vector-width. Though nothing uses min-legal-vector-width yet.

A future patch will add heuristics to preventing inlining with different vector width mismatches. But that code would need to be in inline cost analysis which is separate from the code added here.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337844 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Add test case to show failure to combine away negates that may be created by mul by constant expansion.

Mul by constant can expand to a sequence that ends with a negate. If the next instruction is an add or sub we might be able to fold the negate away.

We currently fail to do this because we explicitly don't add anything to the DAG combine worklist when we expand multiplies. This is primarily to keep the multipy from being reformed, but we should consider adding the users to worklist.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337843 91177308-0d34-0410-b5e6-96231b3b80d8

[docker] Fix LLVM_EXTERNAL_PROJECTS cmake variable value

Summary:
LLVM_ENABLE_PROJECTS expects a semicolon separated project list.

Fixes PR38158.

Reviewers: ilya-biryukov

Reviewed By: ilya-biryukov

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337842 91177308-0d34-0410-b5e6-96231b3b80d8

[MachineOutliner][NFC] Make Candidates own their call information

Before this, TCI contained all the call information for each Candidate.

This moves that information onto the Candidates. As a result, each Candidate
can now supply how it ought to be called. Thus, Candidates will be able to,
say, call the same function in cheaper ways when possible. This also removes
that information from TCI, since it's no longer used there.

A follow-up patch for the AArch64 outliner will demonstrate this.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337840 91177308-0d34-0410-b5e6-96231b3b80d8

[MachineOutliner][NFC] Move missed opt remark into its own function

Having the missed remark code in the middle of `findCandidates` made the
function hard to follow. This yanks that out into a new function,
`emitNotOutliningCheaperRemark`.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337839 91177308-0d34-0410-b5e6-96231b3b80d8

[MachineOutliner][NFC] Sink some candidate logic into OutlinedFunction

Just some simple gardening to improve clarity.

Before, we had something along the lines of

1) Create a std::vector of Candidates
2) Create an OutlinedFunction
3) Create a std::vector of pointers to Candidates
4) Copy those over to the OutlinedFunction and the Candidate list

Now, OutlinedFunctions create the Candidate pointers. They're still copied
over to the main list of Candidates, but it makes it a bit clearer what's
going on.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337838 91177308-0d34-0410-b5e6-96231b3b80d8

Use SCEV to avoid inserting some bounds checks.

This patch uses SCEV to avoid inserting some bounds checks when they are not needed.  This slightly improves the performance of code compiled with the bounds check sanitizer.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@337830 91177308-0d34-0410-b5e6-96231b3b80d8