| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
| |
This adds coverage for Unicode code points which are encoded with
non-zero values in the upper half of the wchar_t.
No functionality change.
llvm-svn: 205251
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 205250
|
| |
|
|
|
|
| |
specialization that would otherwise be selected.
llvm-svn: 205249
|
| |
|
|
|
|
|
|
|
|
|
|
| |
A value of 5 means if we have a split or spill option that has a really
low cost (1 << 14 is the entry frequency), we will choose to spill
or split the really cold path before using a callee-saved register.
This gives us the performance benefit on SPECInt2k and is also conservative.
rdar://16162005
llvm-svn: 205248
|
| |
|
|
|
|
| |
Pass the entire vector type, and not just the element.
llvm-svn: 205247
|
| |
|
|
|
|
|
|
| |
Since dosep.ty started invoking multiple tests in parallel, the FreeBSD
buildbot occasionally has a failure due to os.mkdir returning EEXIST.
Silently ignore that exception, but reraise any other.
llvm-svn: 205246
|
| |
|
|
|
|
|
|
|
| |
This patch is to fix the following warning when compiled with MSVC 64 bit.
warning C4334: '<<' : result of 32-bit shift implicitly converted to 64
bits (was 64-bit shift intended?)
llvm-svn: 205245
|
| |
|
|
| |
llvm-svn: 205244
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the ability to expand large (meaning with more than two unique
defined values) BUILD_VECTOR nodes in terms of SCALAR_TO_VECTOR and (legal)
vector shuffles. There is now no limit of the size we are capable of expanding
this way, although we don't currently do this for vectors with many unique
values because of the default implementation of TLI's
shouldExpandBuildVectorWithShuffles function.
There is currently no functional change to any existing targets because the new
capabilities are not used unless some target overrides the TLI
shouldExpandBuildVectorWithShuffles function. As a result, I've not included a
test case for the new functionality in this commit, but regression tests will
(at least) be added soon when I commit support for the PPC QPX vector
instruction set.
The benefit of committing this now is that it makes the
shouldExpandBuildVectorWithShuffles callback, which had to be added for other
reasons regardless, fully functional. I suspect that other targets will
also benefit from tuning the heuristic.
llvm-svn: 205243
|
| |
|
|
| |
llvm-svn: 205242
|
| |
|
|
|
|
|
| |
This should fix the seemingly-random failures observed on the FreeBSD
buildbot.
llvm-svn: 205241
|
| |
|
|
| |
llvm-svn: 205240
|
| |
|
|
| |
llvm-svn: 205238
|
| |
|
|
|
|
|
|
| |
errors in lld tests.
It's currently unable to parse 'sym + imm' without surrounding parenthesis.
llvm-svn: 205237
|
| |
|
|
| |
llvm-svn: 205236
|
| |
|
|
| |
llvm-svn: 205235
|
| |
|
|
|
|
|
|
| |
argument parsing code.
This removes a diagnostic that is no longer required (the semantic engine now properly handles attribute syntax so __declspec and __attribute__ spellings no longer get mismatched). This caused several testcases to need updating for a slightly different wording.
llvm-svn: 205234
|
| |
|
|
| |
llvm-svn: 205233
|
| |
|
|
|
|
| |
This will be used for a followup patch.
llvm-svn: 205232
|
| |
|
|
|
|
|
| |
If we have two unique values for a v2i64 build vector, this will always result
in two vector loads if we expand using shuffles. Only one is necessary.
llvm-svn: 205231
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two general methods for expanding a BUILD_VECTOR node:
1. Use SCALAR_TO_VECTOR on the defined scalar values and then shuffle
them together.
2. Build the vector on the stack and then load it.
Currently, we use a fixed heuristic: If there are only one or two unique
defined values, then we attempt an expansion in terms of SCALAR_TO_VECTOR and
vector shuffles (provided that the required shuffle mask is legal). Otherwise,
always expand via the stack. Even when SCALAR_TO_VECTOR is not legal, this
can still be a good idea depending on what tricks the target can play when
lowering the resulting shuffle. If the target can't do anything special,
however, and if SCALAR_TO_VECTOR is expanded via the stack, this heuristic
leads to sub-optimal code (two stack loads instead of one).
Because only the target knows whether the SCALAR_TO_VECTORs and shuffles for a
build vector of a particular type are likely to be optimial, this adds a new
TLI function: shouldExpandBuildVectorWithShuffles which takes the vector type
and the count of unique defined values. If this function returns true, then
method (1) will be used, subject to the constraint that all of the necessary
shuffles are legal (as determined by isShuffleMaskLegal). If this function
returns false, then method (2) is always used.
This commit does not enhance the current code to support expanding a
build_vector with more than two unique values using shuffles, but I'll commit
an implementation of the more-general case shortly.
llvm-svn: 205230
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Highlights:
- Registers are resolved much later (by the render method).
Prior to that point, GPR32's/GPR64's are GPR's regardless of register
size. Similarly FGR32's/FGR64's/AFGR64's are FGR's regardless of register
size or FR mode. Numeric registers can be anything.
- All registers are parsed the same way everywhere (even when handling
symbol aliasing)
- One consequence is that all registers can be specified numerically
almost anywhere (e.g. $fccX, $wX). The exception is symbol aliasing
but that can be easily resolved.
- Removes the need for the hasConsumedDollar hack
- Parenthesis and Bracket suffixes are handled generically
- Micromips instructions are parsed directly instead of going through the
standard encodings first.
- rdhwr accepts all 32 registers, and the following instructions that previously
xfailed now work:
ddiv, ddivu, div, divu, cvt.l.[ds], se[bh], wsbh, floor.w.[ds], c.ngl.d,
c.sf.s, dsbh, dshd, madd.s, msub.s, nmadd.s, nmsub.s, swxc1
- Diagnostics involving registers point at the correct character (the $)
- There's only one kind of immediate in MipsOperand. LSA immediates are handled
by the predicate and renderer.
Lowlights:
- Hardcoded '$zero' in the div patterns is handled with a hack.
MipsOperand::isReg() will return true for a k_RegisterIndex token
with Index == 0 and getReg() will return ZERO for this case. Note that it
doesn't return ZERO_64 on isGP64() targets.
- I haven't cleaned up all of the now-unused functions.
Some more of the generic parser could be removed too (integers and relocs
for example).
- insve.df needed a custom decoder to handle the implicit fourth operand that
was needed to make it parse correctly. The difficulty was that the matcher
expected a Token<'0'> but gets an Imm<0>. Adding an implicit zero solved this.
Reviewers: matheusalmeida, vmedic
Reviewed By: matheusalmeida
Differential Revision: http://llvm-reviews.chandlerc.com/D3222
llvm-svn: 205229
|
| |
|
|
|
|
|
| |
pass normally runs at optimization level None, or is part of the
register allocation pipeline.
llvm-svn: 205228
|
| |
|
|
| |
llvm-svn: 205227
|
| |
|
|
|
|
| |
arguments that is currently being used by GNU and C++-style attributes. This allows C++11 attributes with argument lists to be handled properly, fixing the "deprecated", "type_visibility", and capability-related attributes with arguments.
llvm-svn: 205226
|
| |
|
|
|
|
|
| |
No test case is needed, the one in-tree is sufficient. The build-bot
never emailed me because something else had upset it.
llvm-svn: 205225
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 5d5ca72a7876c3dd3dd1db83dc6a0d74be9e2cd1.
Discuss on a better design to raise error when there is a similar group with Gnu
linkonce sections and COMDAT sections.
llvm-svn: 205224
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 205223
|
| |
|
|
| |
llvm-svn: 205222
|
| |
|
|
|
|
|
|
|
|
|
| |
part of an asm .symver directive as being used. This prevents referenced
functions from being internalized and deleted.
Without the patch to LTOModule.cpp, the test case will produce the error:
LLVM ERROR: A @@ version cannot be undefined.
llvm-svn: 205221
|
| |
|
|
| |
llvm-svn: 205220
|
| |
|
|
|
|
|
|
|
| |
This generalises the object file type parsing to all Windows environments. This
is used by cygwin as well as MSVC environments for MCJIT. This also makes the
triple more similar to Chandler's suggestion of a separate field for the object
file format.
llvm-svn: 205219
|
| |
|
|
|
|
|
| |
Don't assume any particular IR Value name, pattern match the names from
the GEP instructions instead.
llvm-svn: 205218
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The definition of a type later in a translation unit may change it's
type from {}* to (%struct.foo*)*. Earlier function definitions may use
the former while more recent definitions might use the later. This is
fine until they interact with one another (like one calling the other).
In these cases, a bitcast is needed because the inalloca must match the
function call but the store to the lvalue which initializes the argument
slot has to match the rvalue's type.
This technique is along the same lines with what the other,
non-inalloca, codepaths perform.
This fixes PR19287.
Reviewers: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3224
llvm-svn: 205217
|
| |
|
|
|
|
|
| |
Now that r205212 was committed, r203483 is no longer necessary; it was a
temporary workaround that only handled a small number of the problematic cases.
llvm-svn: 205216
|
| |
|
|
|
|
|
| |
I removed the underscore at the beginning of the parameter name,
because of a comment from Tim.
llvm-svn: 205215
|
| |
|
|
| |
llvm-svn: 205214
|
| |
|
|
|
|
| |
sanitizer-x86_64-linux-bootstrap buildbot
llvm-svn: 205213
|
| |
|
|
|
|
|
|
| |
This is a more thorough fix for the issue than r203483. An IR pass will run
before NVPTX codegen to make sure there are no invalid symbol names that can't
be consumed by the ptxas assembler.
llvm-svn: 205212
|
| |
|
|
|
|
| |
specifics :)
llvm-svn: 205211
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This adds support for the various NEON intrinsics used by
aarch64-neon-intrinsics.c (originally written for AArch64) and enables the
test.
My implementations are designed to be semantically correct, the actual code
quality looks like its a wash between the two backends, and is frequently
different (hence the large number of CHECK changes).
llvm-svn: 205210
|
| |
|
|
| |
llvm-svn: 205209
|
| |
|
|
| |
llvm-svn: 205208
|
| |
|
|
| |
llvm-svn: 205207
|
| |
|
|
| |
llvm-svn: 205206
|
| |
|
|
| |
llvm-svn: 205205
|
| |
|
|
| |
llvm-svn: 205204
|
| |
|
|
| |
llvm-svn: 205203
|
| |
|
|
|
|
| |
This will be used by the Clang front-end code for vabsd_s64.
llvm-svn: 205202
|
| |
|
|
|
|
| |
hasAttribute. No functional changes.
llvm-svn: 205201
|