Pete Cooper suggested the new API should use ArrayRef instead of SmallVectorImpl. Also adding a test case.

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

Add test cases for PRE w/volatile loads

These tests check that the combination of 227110 (cross block query inst) and 227112 (volatile load semantics) work together properly to allow PRE in cases where a loop contains a volatile access.

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

[X86][SSE] Float comparisons can sometimes be safely commuted

For ordered, unordered, equal and not-equal tests, packed float and double comparison instructions can be safely commuted without affecting the results. This patch checks the comparison mode of the (v)cmpps + (v)cmppd instructions and commutes the result if it can.

Differential Revision: http://reviews.llvm.org/D7178

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

Have the UTF conversion wrappers append a null terminator.

This is especially useful for the UTF8 -> UTF16 direction, since
there is no equivalent of llvm::SmallString<> for wide characters.
This means that anyone who wants a null terminated string is forced
to manually push and pop their own null terminator.

Reviewed by: Reid Kleckner.

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

[X86][PCLMUL] Enable commutation for PCLMUL instructions

Patch to allow (v)pclmulqdq to be commuted - swaps the src registers and inverts the immediate (low/high) src mask.

Differential Revision: http://reviews.llvm.org/D7180

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

Add new HideUnrelatedOptions API that takes a SmallVectorImpl.

Need a new API for clang-modernize that allows specifying a list of option categories to remain visible. This will allow clang-modernize to move off getRegisteredOptions.

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

Line endings fix. NFC.

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

R600: Cleanup or test

Fix broken check lines, use multiple check prefixes,
add an additional test for i1 or.

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

Line endings fix. NFC.

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

bpf: fix build due to 'Move DataLayout back to the TargetMachine'

commit r227113 moved DataLayout

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

[x86][MMX] Rename and cleanup tests: arith, intrinsics and shuffle

- Rename mmx-builtins to mmx-intrinsics to match other intrinsic test naming.
- Remove tests that duplicate functionality from mmx-intrinsics.ll.
- Move arith related tests to mmx-arith.ll.
- MMX related shuffle goes to vector-shuffle-mmx.ll.

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

SimplifyCFG: Omit range checks for switch lookup tables when default is unreachable

The range check would get optimized away later, but we might as well not emit
them in the first place.

http://reviews.llvm.org/D6471

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

SimplifyCFG: don't remove unreachable default switch destinations

An unreachable default destination can be exploited by other optimizations and
allows for more efficient lowering. Both the SDag switch lowering and
LowerSwitch can exploit unreachable defaults.

Also make TurnSwitchRangeICmp handle switches with unreachable default.
This is kind of separate change, but it cannot be tested without the change
above, and I don't want to land the change above without this since that would
regress other tests.

Differential Revision: http://reviews.llvm.org/D6471

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

Make ConstantFoldTerminator() handle switches with unreachable default.

Tested by Transforms/SimplifyCFG/switch-to-br.ll's @unreachable function.

Differential Revision: http://reviews.llvm.org/D6471

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

[NVPTX] Generate a more optimal sequence for select of i1

Instead of creating a pattern like "(p && a) || ((!p) && b)",
just expand the i8 operands to i32 and perform the selp on them.

Fixes PR22246

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

Add a UTF8 to UTF16 conversion wrapper for use in the pdb dumper

This can also be used instead of the WindowsSupport.h ConvertUTF8ToUTF16
helpers, but that will require massaging some character types. The
Windows support routines want wchar_t output, but wchar_t is often 32
bits on non-Windows OSs.

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

Cache the lookup of TargetLowering in the atomic expand pass.

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

[SelectionDAG] Fix assert message copypasta. NFC.

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

Add a FIXME about preferred alignment to DataLayout.

Essentially DataLayout is global and affects the layout of ABI
level objects. Preferred alignment could change on a per function
basis as we change CPU features.

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

[NVPTX] Handle floating-point conversion patterns that are not explicitly ordered or unordered

Fixes PR22322

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

Use a different encoding for debugtrap on PS4.

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

Move DataLayout back to the TargetMachine from TargetSubtargetInfo
derived classes.

Since global data alignment, layout, and mangling is often based on the
DataLayout, move it to the TargetMachine. This ensures that global
data is going to be layed out and mangled consistently if the subtarget
changes on a per function basis. Prior to this all targets(*) have
had subtarget dependent code moved out and onto the TargetMachine.

*One target hasn't been migrated as part of this change: R600. The
R600 port has, as a subtarget feature, the size of pointers and
this affects global data layout. I've currently hacked in a FIXME
to enable progress, but the port needs to be updated to either pass
the 64-bitness to the TargetMachine, or fix the DataLayout to
avoid subtarget dependent features.

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

Refine memory dependence's notion of volatile semantics

According to my reading of the LangRef, volatiles are only ordered with respect to other volatiles. It is entirely legal and profitable to forward unrelated loads over the volatile load. This patch implements this for GVN by refining the transition rules MemoryDependenceAnalysis uses when encountering a volatile.

The added test cases show where the extra flexibility is profitable for local dependence optimizations. I have a related change (227110) which will extend this to non-local dependence (i.e. PRE), but that's essentially orthogonal to the semantic change in this patch. I have tested the two together and can confirm that PRE works over a volatile load with both changes.  I will be submitting a PRE w/volatiles test case seperately in the near future.

Differential Revision: http://reviews.llvm.org/D6901

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

Model sqrtsd as a binary operation with one source operand tied to the destination (PR14221)

This patch fixes the following miscompile:

define void @sqrtsd(<2 x double> %a) nounwind uwtable ssp {
  %0 = tail call <2 x double> @llvm.x86.sse2.sqrt.sd(<2 x double> %a) nounwind
  %a0 = extractelement <2 x double> %0, i32 0
  %conv = fptrunc double %a0 to float
  %a1 = extractelement <2 x double> %0, i32 1
  %conv3 = fptrunc double %a1 to float
  tail call void @callee2(float %conv, float %conv3) nounwind
  ret void
}

Current codegen:

sqrtsd %xmm0, %xmm1        ## high element of %xmm1 is undef here
xorps %xmm0, %xmm0
cvtsd2ss %xmm1, %xmm0
shufpd $1, %xmm1, %xmm1
cvtsd2ss %xmm1, %xmm1 ## operating on undef value
jmp _callee

This is a continuation of http://llvm.org/viewvc/llvm-project?view=revision&revision=224624 ( http://reviews.llvm.org/D6330 )
which was itself a continuation of r167064 ( http://llvm.org/viewvc/llvm-project?view=revision&revision=167064 ).

All of these patches are partial fixes for PR14221 ( http://llvm.org/bugs/show_bug.cgi?id=14221 );
this should be the final patch needed to resolve that bug.

Differential Revision: http://reviews.llvm.org/D6885

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

Pass QueryInst down through non-local dependency calculation

This change is mostly motivated by exposing information about the original query instruction to the actual scanning work in getPointerDependencyFrom when used by GVN PRE. In a follow up change, I will use this to be more precise with regards to the semantics of volatile instructions encountered in the scan of a basic block.

Worth noting, is that this change (despite appearing quite simple) is not semantically preserving. By providing more information to the helper routine, we allow some optimizations to kick in that weren't previously able to (when called from this code path.) In particular, we see that treatment of !invariant.load becomes more precise. In theory, we might see a difference with an ordered/atomic instruction as well, but I'm having a hard time actually finding a test case which shows that.

Test wise, I've included new tests for !invariant.load which illustrate this difference. I've also included some updated TBAA tests which highlight that this change isn't needed for that optimization to kick in - it's handled inside alias analysis itself.

Eventually, it would be nice to factor the !invariant.load handling inside alias analysis as well.

Differential Revision: http://reviews.llvm.org/D6895

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

Revert GCStrategy ownership changes

This change reverts the interesting parts of 226311 (and 227046).  This change introduced two problems, and I've been convinced that an alternate approach is preferrable anyways.

The bugs were:
- Registery appears to require all users be within the same linkage unit.  After this change, asking for "statepoint-example" in Transform/ would sometimes get you nullptr, whereas asking the same question in CodeGen would return the right GCStrategy.  The correct long term fix is to get rid of the utter hack which is Registry, but I don't have time for that right now.  227046 appears to have been an attempt to fix this, but I don't believe it does so completely.
- GCMetadataPrinter::finishAssembly was being called more than once per GCStrategy.  Each Strategy was being added to the GCModuleInfo multiple times.

Once I get time again, I'm going to split GCModuleInfo into the gc.root specific part and a GCStrategy owning Analysis pass.  I'm probably also going to kill off the Registry.  Once that's done, I'll move the new GCStrategyAnalysis and all built in GCStrategies into Analysis.  (As original suggested by Chandler.)  This will accomplish my original goal of being able to access GCStrategy from Transform/  without adding all of the builtin GCs to IR/.

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

Teach raw_ostream to support hex formatting without a prefix '0x'.

Previously using format_hex() would always print a 0x prior to the
hex characters.  This allows this to be optional, so that one can
choose to print (e.g.) 255 as either 0xFF or just FF.

Differential Revision: http://reviews.llvm.org/D7151

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

Remove trailing whitespace. NFC ®

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

Remove trailing whitespace.

Also test commit email processing by including this char: '®'

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

Move the Mips target to storing the ABI in the TargetMachine rather
than on MipsSubtargetInfo.

This required a bit of massaging in the MC level to handle this since
MC is a) largely a collection of disparate classes with no hierarchy,
and b) there's no overarching equivalent to the TargetMachine, instead
only the subtarget via MCSubtargetInfo (which is the base class of
TargetSubtargetInfo).

We're now storing the ABI in both the TargetMachine level and in the
MC level because the AsmParser and the TargetStreamer both need to
know what ABI we have to parse assembly and emit objects. The target
streamer has a pointer to the one in the asm parser and is updated
when the asm parser is created. This is fragile as the FIXME comment
notes, but shouldn't be a problem in practice since we always
create an asm parser before attempting to emit object code via the
assembler. The TargetMachine now contains the ABI so that the DataLayout
can be constructed dependent upon ABI.

All testcases have been updated to use the -target-abi command line
flag so that we can set the ABI without using a subtarget feature.

Should be no change visible externally here.

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

Store the passed in CPU name string so that it can be accessed later.

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

Fix incorrect partial aliasing
Update testcases

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

Fix delegation

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

fix line-endings; NFC

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

[Support][Windows] Disable error dialog boxes when stack trace printing is enabled.

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

Putting all the standard tool options into a "Generic" category.

Summary:
This puts all the options that CommandLine.cpp implements into a category so that the APIs to hide options can not hide based on the generic category instead of string matching a partial list of argument strings.

This patch is pretty simple and straight forward but it does impact the -help output of all tools using cl::opt. Specifically the options implemented in CommandLine.cpp (help, help-list, help-hidden, help-list-hidden, print-options, print-all-options, version) are all grouped together into an Option category, and these options are never hidden by the cl::HideUnrelatedOptions API.

Reviewers: dexonsmith, chandlerc, majnemer

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7150

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

[MC] The PS4's ELF OSABI value is the same as FreeBSD.

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

Teach the autoconf machinery about the PS4 triple.

(I think the last checkin, r227060, got lost from the mailing lists because of the (R) in the comment.)

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

[mips] Enable arithmetic and binary operations for the i128 data type.

Summary:
This patch adds support for some operations that were missing from
128-bit integer types (add/sub/mul/sdiv/udiv... etc.). With these
changes we can support the __int128_t and __uint128_t data types
from C/C++.

Depends on D7125

Reviewers: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7143

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

[mips] Add tests for bitwise binary and integer arithmetic operators.

Reviewers: dsanders

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D7125

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

The canonical CPU variant for ARM according to config.guess uses a
suffix it seems:

    # ./config.guess
    earmv7hfeb-unknown-netbsd7.99.4

Extend the triple parsing to support this. Avoid running the ARM parser
multiple times because StringSwitch is not lazy.

Reviewers: Renato Golin, Tim Northover

Differential Revision: http://reviews.llvm.org/D7166

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

When disassembler meets compact jump instructions for r6 it crashes as the access to operands array is out of range. This patch removes dedicated decoder method that wrongly handles decoding of these instructions.

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

Revert "[mips] Fix assertion on i128 addition/subtraction on MIPS64"

This reverts commit r227003. Support for addition/subtraction and
various other operations for the i128 data type will be added in a
future commit based on the review D7143.

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

Revert llvm/test/MC/ELF/noexec.s in r227074, "Fix a problem where the AArch64 ELF assembler was failing with"

It should be split into target-specific location.

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

SLPVectorizer: fix wrong scheduling of atomic load/stores.

This fixes PR22306.

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

Correct the header guard for MipsABIInfo.h.

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

Fix a problem where the AArch64 ELF assembler was failing with
-no-exec-stack. This was due to it not deriving from the correct
asm info base class and missing the override for the exec
stack section query. Added another line to the noexec test
line to make sure this doesn't regress.

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

[X86] Change comparision immediate type to i8 in test cases for AVX512 floating point comparisons. The type was already changed in the definitions and was being auto upgraded to the new type.

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

[X86] Use i8 immediate for comparison type on AVX512 packed integer instructions. This matches floating point equivalents. Includes autoupgrade support to convert old code.

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

Add the triple for the Sony Playstation®4.

Lots more to follow.

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

Debug info: Fix PR22296 by omitting the DW_AT_location if we lost the
physical register that is described in a DBG_VALUE.

In the testcase the DBG_VALUE describing "p5" becomes unavailable
because the register its address is in is clobbered and we (currently)
aren't smart enough to realize that the value is rematerialized immediately
after the DBG_VALUE and/or is actually a stack slot.

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

[PowerPC] Revert ppc64le-aggregates.ll test changes from r227053

It appears we have different behavior with and without -mcpu=pwr8 even
with ppc64le defaulting to POWER8.  The failure appears as follows:

/home/bb/cmake-llvm-x86_64-linux/llvm-project/llvm/test/CodeGen/PowerPC/ppc64le-aggregates.ll:268:14: error: expected string not found in input
; CHECK-DAG: lfs 1, 0([[REG]])
             ^
<stdin>:497:11: note: scanning from here
 ld 3, .LC1@toc@l(3)
          ^
<stdin>:497:11: note: with variable "REG" equal to "3"
 ld 3, .LC1@toc@l(3)
          ^
<stdin>:514:2: note: possible intended match here
 lfs 1, 0(4)
 ^

Reverting this particular test case change.  Nemanja, please have a look
at the reason for the failure.

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

[PowerPC] Reset the baseline for ppc64le to be equivalent to pwr8

Test by Nemanja Ivanovic.

Since ppc64le implies POWER8 as a minimum, it makes sense that the
same features are included. Since the pwr8 processor model will likely
be getting new features until the implementation is complete, I
created a new list to add these updates to. This will include them in
both pwr8 and ppc64le.

Furthermore, it seems that it would make sense to compose the feature
lists for other processor models (pwr3 and up). Per discussion in the
review, I will make this change in a subsequent patch.

In order to test the changes, I've added an additional run step to
test cases that specify -march=ppc64le -mcpu=pwr8 to omit the -mcpu
option. Since the feature lists are the same, the behaviour should be
unchanged.

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

[docs] Add link to the MIPS 64-bit ELF object file specification

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

Instantiate Registry<GCStrategy> in LLVMCore, to let it available on Win32 DLL.

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

[ELFYAML] Support mips64 relocation record format in yaml2obj/obj2yaml

MIPS64 ELF file has a very specific relocation record format. Each
record might specify up to three relocation operations. So the `r_info`
field in fact consists of three relocation type sub-fields and optional
code of "special" symbols.

http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf
page 40

The patch implements support of the MIPS64 relocation record format in
yaml2obj/obj2yaml tools by introducing new optional Relocation fields:
Type2, Type3, and SpecSym. These fields are recognized only if the
object/YAML file relates to the MIPS64 target.

Differential Revision: http://reviews.llvm.org/D7136

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

AVX-512: Changes in operations on masks registers for KNL and SKX
- Added KSHIFTB/D/Q for skx
- Added KORTESTB/D/Q for skx
- Fixed store operation for v8i1 type for KNL
- Store size of v8i1, v4i1 and v2i1 are changed to 8 bits

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

Orc/IRCompileLayer.h: Avoid non-static initializer.

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

OrcJIT: Avoid non-static initializers.

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

Orc/LLVMBuild.txt: Prune redundant "Target" in libdeps.

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

[X86] Give scalar VRNDSCALE instructions priority in AVX512 mode.

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

Simplify a multiclass. No functional change.

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

Remove tab characters. NFC

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

Implemented cost model for masked load/store operations.

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

[X86] Replace i32i8imm on SSE/AVX instructions with i32u8imm which will make the assembler bounds check them. It will also make them print as unsigned.

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

[X86] Use u8imm in several places that used i32i8imm that don't require an i32 type.

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

Remove tab characters. NFC.

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

[PM] Remove the restricted visibility from the instcombine worklist. Now
that library consumers access the instcombine pass directly, they also
(transitively) access the worklist. Also, it would need to be used
directly in order to have a useful utility if we ever want that.

This should fix some warnings since I moved this code. Sorry for the
trouble.

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

Remove a few more redundant ExecutionEngine regression tests.

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

Fixup debug information references.

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

Update references to lines of code count.

The number of lines of code in Kaleidoscope has risen from the
previously reported 700 to 986 according to the cloc tool. This tools
was run on the toy.cpp file from Chapter 8.

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

InstrProf: Add operator!= to coverage counters

I'll use this in clang shortly. Also makes the operator definition
style more consistent in this class.

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

llvm-cov: Only combine segments if they overlap exactly

If two coverage segments cover the same area we need to combine them,
as per r218432. OTOH, just because they start at the same place
doesn't mean they cover the same area. This fixes the check to be more
exact about this.

This is pretty hard to test right now. The frontend doesn't currently
emit regions that start at the same place but don't overlap, but some
upcoming work changes this.

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

Revert r227013 "Add visibility attribute for InstCombinePass (r226987)."

Buildbot breakage.
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/21749

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

CodeGen: drive-by formatting clean ups

Minor tweaks to whitespace formatting that I noticed was off.  NFC.

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

Add visibility attribute for InstCombinePass (r226987).

Warning by gcc:
'llvm::InstCombinePass' declared with greater visibility than the type of its field 'llvm::InstCombinePass::Worklist' [-Wattributes]

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

DebugInfo: Fix use after return found by asan.

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

[Orc] Add TransformUtils to Orc's dependency list.

Patch by Jan Vesely. Thanks Jan!

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

Remove a number of redundant ExecutionEngine regression tests.

These tests used to test the legacy JIT but since that has been removed they're
just redundantly testing MCJIT. Remove them and just leave their counterparts in
test/ExecutionEngine/MCJIT.

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

bpf: add missing lit.local.cfg

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

BPF backend

Summary:
V8->V9:
- cleanup tests

V7->V8:
- addressed feedback from David:
- switched to range-based 'for' loops
- fixed formatting of tests

V6->V7:
- rebased and adjusted AsmPrinter args
- CamelCased .td, fixed formatting, cleaned up names, removed unused patterns
- diffstat: 3 files changed, 203 insertions(+), 227 deletions(-)

V5->V6:
- addressed feedback from Chandler:
- reinstated full verbose standard banner in all files
- fixed variables that were not in CamelCase
- fixed names of #ifdef in header files
- removed redundant braces in if/else chains with single statements
- fixed comments
- removed trailing empty line
- dropped debug annotations from tests
- diffstat of these changes:
  46 files changed, 456 insertions(+), 469 deletions(-)

V4->V5:
- fix setLoadExtAction() interface
- clang-formated all where it made sense

V3->V4:
- added CODE_OWNERS entry for BPF backend

V2->V3:
- fix metadata in tests

V1->V2:
- addressed feedback from Tom and Matt
- removed top level change to configure (now everything via 'experimental-backend')
- reworked error reporting via DiagnosticInfo (similar to R600)
- added few more tests
- added cmake build
- added Triple::bpf
- tested on linux and darwin

V1 cover letter:
---------------------
recently linux gained "universal in-kernel virtual machine" which is called
eBPF or extended BPF. The name comes from "Berkeley Packet Filter", since
new instruction set is based on it.
This patch adds a new backend that emits extended BPF instruction set.

The concept and development are covered by the following articles:
http://lwn.net/Articles/599755/
http://lwn.net/Articles/575531/
http://lwn.net/Articles/603983/
http://lwn.net/Articles/606089/
http://lwn.net/Articles/612878/

One of use cases: dtrace/systemtap alternative.

bpf syscall manpage:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b4fc1a460f3017e958e6a8ea560ea0afd91bf6fe

instruction set description and differences vs classic BPF:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/filter.txt

Short summary of instruction set:
- 64-bit registers
  R0      - return value from in-kernel function, and exit value for BPF program
  R1 - R5 - arguments from BPF program to in-kernel function
  R6 - R9 - callee saved registers that in-kernel function will preserve
  R10     - read-only frame pointer to access stack
- two-operand instructions like +, -, *, mov, load/store
- implicit prologue/epilogue (invisible stack pointer)
- no floating point, no simd

Short history of extended BPF in kernel:
interpreter in 3.15, x64 JIT in 3.16, arm64 JIT, verifier, bpf syscall in 3.18, more to come in the future.

It's a very small and simple backend.
There is no support for global variables, arbitrary function calls, floating point, varargs,
exceptions, indirect jumps, arbitrary pointer arithmetic, alloca, etc.
From C front-end point of view it's very restricted. It's done on purpose, since kernel
rejects all programs that it cannot prove safe. It rejects programs with loops
and with memory accesses via arbitrary pointers. When kernel accepts the program it is
guaranteed that program will terminate and will not crash the kernel.

This patch implements all 'must have' bits. There are several things on TODO list,
so this is not the end of development.
Most of the code is a boiler plate code, copy-pasted from other backends.
Only odd things are lack or < and <= instructions, specialized load_byte intrinsics
and 'compare and goto' as single instruction.
Current instruction set is fixed, but more instructions can be added in the future.

Signed-off-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Subscribers: majnemer, chandlerc, echristo, joerg, pete, rengolin, kristof.beyls, arsenm, t.p.northover, tstellarAMD, aemerson, llvm-commits

Differential Revision: http://reviews.llvm.org/D6494

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

[mips] Fix 'jumpy' debug line info around calls.

Summary:
At the moment, address calculation is taking the debug line info from the
address node (e.g. TargetGlobalAddress). When a function is called multiple
times, this results in output of the form:

  .loc $first_call_location
  .. address calculation ..
  .. function call ..
  .. address calculation ..
  .loc $second_call_location
  .. function call ..
  .loc $first_call_location
  .. address calculation ..
  .loc $third_call_location
  .. function call ..

This patch makes address calculations for function calls take the debug line
info for the call node and results in output of the form:
  .loc $first_call_location
  .. address calculation ..
  .. function call ..
  .loc $second_call_location
  .. address calculation ..
  .. function call ..
  .loc $third_call_location
  .. address calculation ..
  .. function call ..

All other address calculations continue to use the address node.

Test Plan: Fixes test/DebugInfo/multiline.ll on a mips host.

Subscribers: dblaikie, llvm-commits

Differential Revision: http://reviews.llvm.org/D7050

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

Update of the gold-plugin.cpp code to match Chandler's changes (r226981)

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

[mips] Fix assertion on i128 addition/subtraction on MIPS64

Summary:
In addition to the included tests, this fixes
test/CodeGen/Generic/i128-addsub.ll on a mips64 host.

Reviewers: atanasyan, sagar, vmedic

Reviewed By: vmedic

Subscribers: sdkie, llvm-commits

Differential Revision: http://reviews.llvm.org/D6610

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

[DAG] Fix wrong canonicalization performed on shuffle nodes.

This fixes a regression introduced by r226816.
When replacing a splat shuffle node with a constant build_vector,
make sure that the new build_vector has a valid number of elements.

Thanks to Patrik Hagglund for reporting this problem and providing a
small reproducible.

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

[PM] General doxygen and comment cleanup for this pass.

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

[PM] Reformat this code with clang-format so that I can use clang-format
when refactoring for the new pass manager without introducing too many
formatting changes into meaning full diffs.

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

[PM] Port LowerExpectIntrinsic to the new pass manager.

This just lifts the logic into a static helper function, sinks the
legacy pass to be a trivial wrapper of that helper fuction, and adds
a trivial wrapper for the new PM as well. Not much to see here.

I switched a test case to run in both modes, but we have to strip the
dead prototypes separately as that pass isn't in the new pass manager
(yet).

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

[PM] Change LowerExpectIntrinsic to actually return true when it has
changed the IR. This is particularly easy as we can just look for the
existence of any expect intrinsic at all to know whether we've changed
the IR.

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

[PM] Use a more appropriate name for the statistics variable in
lower-expect, as we don't have 'if's in the IR and we use it for
switches as well.

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

[PM] Switch tihs code to use a range based for loop over the function.

We can't switch the loop over the instructions because it needs to
early-increment the iterator.

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

[PM] Use a SmallVector instead of std::vector to avoid heap allocations
for small switches, and avoid using a complex loop to set up the
weights.

We know what the baseline weights will be so we can just resize the
vector to contain all that value and clobber the one slot that is
likely. This seems much more direct than the previous code that tested
at every iteration, and started off by zeroing the vector.

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

[PM] Pull the two helpers for this pass into static functions. There are
no members for them to use.

Also, make them accept references as there is no possibility of a null
pointer.

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

[PM] Add a basic doxygen comment for this pass.

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

[PM] Clean up the formatting of the LowerExpectIntrinsic pass prior to
refactoring its code.

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

[PM] Move the LowerExpectIntrinsic pass to the Scalar library.

It was already in the Scalar header and referenced extensively as being
in this library, the source file was just in the utils directory for
some reason. No actual functionality changed. I noticed as it didn't
make sense to add a pass header to the utils headers.

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

If we see UTF-8 BOM sequence at the beginning of a response file, we shall
remove these bytes before parsing.

Phabricator Revision: http://reviews.llvm.org/D7156

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

[PM] Port instcombine to the new pass manager!

This is exciting as this is a much more involved port. This is
a complex, existing transformation pass. All of the core logic is shared
between both old and new pass managers. Only the access to the analyses
is separate because the actual techniques are separate. This also uses
a bunch of different and interesting analyses and is the first time
where we need to use an analysis across an IR layer.

This also paves the way to expose instcombine utility functions. I've
got a static function that implements the core pass logic over
a function which might be mildly interesting, but more interesting is
likely exposing a routine which just uses instructions *already in* the
worklist and combines until empty.

I've switched one of my favorite instcombine tests to run with both as
well to make sure this keeps working.

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

[Bitcode] Diagnose errors instead of asserting from bad input

Eventually we can make some of these pass the error along to the caller.

Reports a fatal error if:
We find an invalid abbrev record
We try to get an invalid abbrev number
We can't fill the current word due to an EOF

Fixed an invalid bitcode test to check for output with FileCheck

Bugs found with afl-fuzz

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

[PM] Rework how the TargetLibraryInfo pass integrates with the new pass
manager to support the actual uses of it. =]

When I ported instcombine to the new pass manager I discover that it
didn't work because TLI wasn't available in the right places. This is
a somewhat surprising and/or subtle aspect of the new pass manager
design that came up before but I think is useful to be reminded of:

While the new pass manager *allows* a function pass to query a module
analysis, it requires that the module analysis is already run and cached
prior to the function pass manager starting up, possibly with
a 'require<foo>' style utility in the pass pipeline. This is an
intentional hurdle because using a module analysis from a function pass
*requires* that the module analysis is run prior to entering the
function pass manager. Otherwise the other functions in the module could
be in who-knows-what state, etc.

A somewhat surprising consequence of this design decision (at least to
me) is that you have to design a function pass that leverages
a module analysis to do so as an optional feature. Even if that means
your function pass does no work in the absence of the module analysis,
you have to handle that possibility and remain conservatively correct.
This is a natural consequence of things being able to invalidate the
module analysis and us being unable to re-run it. And it's a generally
good thing because it lets us reorder passes arbitrarily without
breaking correctness, etc.

This ends up causing problems in one case. What if we have a module
analysis that is *definitionally* impossible to invalidate. In the
places this might come up, the analysis is usually also definitionally
trivial to run even while other transformation passes run on the module,
regardless of the state of anything. And so, it follows that it is
natural to have a hard requirement on such analyses from a function
pass.

It turns out, that TargetLibraryInfo is just such an analysis, and
InstCombine has a hard requirement on it.

The approach I've taken here is to produce an analysis that models this
flexibility by making it both a module and a function analysis. This
exposes the fact that it is in fact safe to compute at any point. We can
even make it a valid CGSCC analysis at some point if that is useful.
However, we don't want to have a copy of the actual target library info
state for each function! This state is specific to the triple. The
somewhat direct and blunt approach here is to turn TLI into a pimpl,
with the state and mutators in the implementation class and the query
routines primarily in the wrapper. Then the analysis can lazily
construct and cache the implementations, keyed on the triple, and
on-demand produce wrappers of them for each function.

One minor annoyance is that we will end up with a wrapper for each
function in the module. While this is a bit wasteful (one pointer per
function) it seems tolerable. And it has the advantage of ensuring that
we pay the absolute minimum synchronization cost to access this
information should we end up with a nice parallel function pass manager
in the future. We could look into trying to mark when analysis results
are especially cheap to recompute and more eagerly GC-ing the cached
results, or we could look at supporting a variant of analyses whose
results are specifically *not* cached and expected to just be used and
discarded by the consumer. Either way, these seem like incremental
enhancements that should happen when we start profiling the memory and
CPU usage of the new pass manager and not before.

The other minor annoyance is that if we end up using the TLI in both
a module pass and a function pass, those will be produced by two
separate analyses, and thus will point to separate copies of the
implementation state. While a minor issue, I dislike this and would like
to find a way to cleanly allow a single analysis instance to be used
across multiple IR unit managers. But I don't have a good solution to
this today, and I don't want to hold up all of the work waiting to come
up with one. This too seems like a reasonable thing to incrementally
improve later.

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