| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
RuntimeDyld.
This should fix http://llvm.org/PR22593.
llvm-svn: 229343
|
| |
|
|
|
|
| |
requiring the macro. NFC; LLVM edition.
llvm-svn: 229340
|
| |
|
|
|
|
|
|
|
|
|
| |
Introduces a subset of C++14 integer sequences in STLExtras. This is
just enough to support unpacking a std::tuple into the arguments of
snprintf, we can add more of it when it's actually needed.
Also removes an ancient macro hack that leaks a macro into the global
namespace. Clean up users that made use of the convenient hack.
llvm-svn: 229337
|
| |
|
|
|
|
| |
macro. NFC; LLVM edition.
llvm-svn: 229335
|
| |
|
|
| |
llvm-svn: 229330
|
| |
|
|
|
|
| |
This change is a logical suspect in 22587 and 22590. Given it's of minimal importanance and I can't get clang to build on my home machine, I'm reverting so that I can deal with this next week.
llvm-svn: 229322
|
| |
|
|
|
|
| |
We can use a range-based for for the operands loop too; NFC.
llvm-svn: 229319
|
| |
|
|
|
|
| |
Convert a few loops to range-based fors; NFC.
llvm-svn: 229318
|
| |
|
|
|
|
| |
We prefer to put the * with the variable, not with the type; NFC.
llvm-svn: 229317
|
| |
|
|
|
|
| |
Bring another local variable in compliance with our naming conventions, NFC.
llvm-svn: 229316
|
| |
|
|
|
|
| |
Bring some local variables in compliance with our naming conventions, NFC.
llvm-svn: 229315
|
| |
|
|
| |
llvm-svn: 229312
|
| |
|
|
|
|
|
|
|
|
| |
This patch refactors the existing lowerVectorShuffleAsByteShift function to add support for 256-bit vectors on AVX2 targets.
It also fixes a tablegen issue that prevented the lowering of vpslldq/vpsrldq vec256 instructions.
Differential Revision: http://reviews.llvm.org/D7596
llvm-svn: 229311
|
| |
|
|
|
|
|
|
|
|
|
|
| |
when that will allow it to lower with a single permute instead of
multiple permutes.
It tries to detect when it will only have to do a single permute in
either case to maximize folding of loads and such.
This cuts a *lot* of the avx2 shuffle permute counts in half. =]
llvm-svn: 229309
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
directly into blends of the splats.
These patterns show up even very late in the vector shuffle lowering
where we don't have any chance for DAG combining to kick in, and
blending is a tremendously simpler operation to model. By coercing the
shuffle into a blend we can much more easily match and lower shuffles of
splats.
Immediately with this change there are significantly more blends being
matched in the x86 vector shuffle lowering.
llvm-svn: 229308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vectors and detect equivalent inputs.
This lets the code match unpck-style instructions when only one of the
inputs are lined up but the other input is a splat and so which lanes we
pull from doesn't matter. Today, this doesn't really happen, but just by
accident. I have a patch that normalizes how we shuffle splats, and with
that patch this will be necessary for a lot of the mask equivalence
tests to work.
I don't really know how to write a test case for this specific change
until the other change lands though.
llvm-svn: 229307
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
don't try to do element insertion for non-zero-index floating point
vectors.
We don't have any useful patterns or lowering for element insertion into
high elements of a floating point vector, and the generic shuffle
lowering will end up being better -- namely it will fall back to unpck.
But we should try to handle other forms of element insertion before
matching unpck patterns.
While this doesn't matter much right now, I'm working on a patch that
makes unpck matching much more powerful, and that patch will break
without this re-ordering.
llvm-svn: 229306
|
| |
|
|
|
|
|
|
|
| |
I was somewhat surprised this pattern really came up, but it does. It
seems better to just directly handle it than try to special case every
place where we end up forming a shuffle that devolves to a shuffle of
a zero vector.
llvm-svn: 229301
|
| |
|
|
|
|
| |
a -Wparentheses complaint from GCC.
llvm-svn: 229300
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
subvectors from buildvectors. That doesn't really make any sense and it
breaks all of the down-stream matching of buildvectors to cleverly lower
shuffles.
With this, we now get the shift-based lowering of 256-bit vector
shuffles with AVX1 when we split them into 128-bit vectors. We also do
much better on the zero-extension patterns, although there remains quite
a bit of room for improvement here.
llvm-svn: 229299
|
| |
|
|
|
|
|
|
|
|
|
|
| |
least in theory.
I don't actually have a test case that benefits from this, but
theoretically, it could come up, and I don't want to try to think about
whether this is the culprit or something else is, so I'd rather just
make this code powerful. =/ Makes me sad that I can't really test it
though.
llvm-svn: 229298
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lowerings -- one which decomposes into an initial blend followed by
a permute.
Particularly on newer chips, blends are handled independently of
shuffles and so this is much less bottlenecked on the single port that
floating point shuffles are executed with on Intel.
I'll be adding this lowering to a bunch of other code paths in
subsequent commits to handle still more places where we can effectively
leverage blends when they're available in the ISA.
llvm-svn: 229292
|
| |
|
|
|
|
|
| |
We already have implementation for cost calculation for
masked memory operations. I just call it from the loop vectorizer.
llvm-svn: 229290
|
| |
|
|
|
|
| |
instructions.
llvm-svn: 229287
|
| |
|
|
|
|
|
|
|
|
|
| |
test.
This was just a matter of the DAG combine for vector shuffles being too
aggressive. This is a bit of a grey area, but I think generally if we
can re-use intermediate shuffles, we should. Certainly, given the test
cases I have available, this seems like the right call.
llvm-svn: 229285
|
| |
|
|
|
|
| |
This makes the assembly matching consistent across all AVX512 instructions. Without this we were allowing some AVX512 instructions to be parsed always, but not the foundation instructions.
llvm-svn: 229280
|
| |
|
|
|
|
| |
encodings linear which can then be used to simplify some other code.
llvm-svn: 229279
|
| |
|
|
|
|
|
|
|
|
| |
Patch to allow XOP instructions (integer comparison and integer multiply-add) to be commuted. The comparison instructions sometimes require the compare mode to be flipped but the remaining instructions can use default commutation modes.
This patch also sets the SSE domains of all the XOP instructions.
Differential Revision: http://reviews.llvm.org/D7646
llvm-svn: 229267
|
| |
|
|
|
|
| |
mnemonic aliases. They'll now print with the alias the parser received instead of converting to the explicit immediate form.
llvm-svn: 229266
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "dereferenceable" attribute cannot be added via .addAttribute(),
since it also expects a size in bytes. AttrBuilder#addAttribute or
AttributeSet#addAttribute is wrapped by classes Function, InvokeInst,
and CallInst. Add corresponding wrappers to
AttrBuilder#addDereferenceableAttr.
Having done this, propagate the dereferenceable attribute via
gc.relocate, adding a test to exercise it. Note that -datalayout is
required during execution over and above -instcombine, because
InstCombine only optionally requires DataLayoutPass.
Differential Revision: http://reviews.llvm.org/D7510
llvm-svn: 229265
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Canonicalize access to function attributes to use the simpler API.
getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind)
=> getFnAttribute(Kind)
getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind)
=> hasFnAttribute(Kind)
llvm-svn: 229261
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Canonicalize access to function attributes to use the simpler API.
getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind)
=> getFnAttribute(Kind)
getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind)
=> hasFnAttribute(Kind)
llvm-svn: 229260
|
| |
|
|
|
|
|
| |
Added test CodeGen/X86/constant-hoisting-optnone.ll to verify that
pass Constant Hoisting is not run on optnone functions.
llvm-svn: 229258
|
| |
|
|
| |
llvm-svn: 229256
|
| |
|
|
|
|
| |
the assert. Fixes -Wunused-variable on non-asserts builds.
llvm-svn: 229250
|
| |
|
|
|
|
| |
This version passes the OpenCL conformance test.
llvm-svn: 229239
|
| |
|
|
| |
llvm-svn: 229238
|
| |
|
|
|
|
|
|
|
| |
This should allow finally fixing the f64 fdiv implementation.
Test is disabled for VI since there seems to be a problem with one
of the buffer load instructions on it.
llvm-svn: 229236
|
| |
|
|
| |
llvm-svn: 229235
|
| |
|
|
| |
llvm-svn: 229234
|
| |
|
|
| |
llvm-svn: 229233
|
| |
|
|
|
|
|
|
|
|
| |
Dumping the global scope contains a lot of very uninteresting
things and is generally polluted with a lot of random junk.
Furthermore, it dumps values unsorted, making it hard to read.
This patch dumps known interesting types only, and as a side
effect sorts the list by symbol type.
llvm-svn: 229232
|
| |
|
|
| |
llvm-svn: 229231
|
| |
|
|
|
|
| |
This apparently got lost in the VI changes.
llvm-svn: 229230
|
| |
|
|
| |
llvm-svn: 229228
|
| |
|
|
| |
llvm-svn: 229227
|
| |
|
|
|
|
|
| |
This shows up without optimizations when vcc is required
to be used.
llvm-svn: 229226
|
| |
|
|
|
|
| |
This hopefully should be fixed when VReg_1 is removed.
llvm-svn: 229225
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Canonicalize access to function attributes to use the simpler API.
getAttributes().getAttribute(AttributeSet::FunctionIndex, Kind)
=> getFnAttribute(Kind)
getAttributes().hasAttribute(AttributeSet::FunctionIndex, Kind)
=> hasFnAttribute(Kind)
llvm-svn: 229224
|
| |
|
|
|
|
|
| |
This is really a 32-bit register, if we try to check the size of it,
we want 32-bits.
llvm-svn: 229223
|