| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
differ from the SSE/AVX versions by the register class, but register class has no bearing on isel.
llvm-svn: 271623
|
| |
|
|
|
|
|
|
| |
This reverts r271599, it broke the integration tests.
More places than I expected had nontrival return types in imports, or
else the check was wrong.
llvm-svn: 271606
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Under emscripten, C code can take the address of a function implemented
in Javascript (which is exposed via an import in wasm). Because imports
do not have linear memory address in wasm, we need to generate a thunk
to be the target of the indirect call; it call the import directly.
To make this possible, LLVM needs to emit the type signatures for these
functions, because they may not be called directly or referred to other
than where the address is taken.
This uses s new .s directive (.functype) which specifies the signature.
Differential Revision: http://reviews.llvm.org/D20891
llvm-svn: 271599
|
| |
|
|
|
|
|
| |
It can still report the base register, and the uses give up when it
fails.
llvm-svn: 271575
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is effectively a revert of:
http://reviews.llvm.org/rL249702 - [InstCombine] transform masking off of an FP sign bit into a fabs() intrinsic call (PR24886)
and:
http://reviews.llvm.org/rL249701 - [ValueTracking] teach computeKnownBits that a fabs() clears sign bits
and a reimplementation as a DAG combine for targets that have IEEE754-compliant fabs/fneg instructions.
This is intended to resolve the objections raised on the dev list:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098154.html
and:
https://llvm.org/bugs/show_bug.cgi?id=24886#c4
In the interest of patch minimalism, I've only partly enabled AArch64. PowerPC, MIPS, x86 and others can enable later.
Differential Revision: http://reviews.llvm.org/D19391
llvm-svn: 271573
|
| |
|
|
|
|
|
|
|
| |
There are a lot of different kinds of loads to test for,
and these were scattered around inconsistently with
some redundancy. Try to comprehensively test all loads
in a consistent way.
llvm-svn: 271571
|
| |
|
|
| |
llvm-svn: 271567
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the processor name failed to parse for amdgcn,
the resulting output would have R600 ISA in it.
If the processor name was missing or invalid for R600,
the wavefront size would not be set and there would be
crashes from missing itinerary data.
Fixes crashes in future commit caused by dividing by the unset/0
wavefront size.
llvm-svn: 271561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've been pretending that segments are i8imm since the initial
support (r68645), predating the addition of the SEGMENT_REG class
(r81895). That happens to works, but is wrong, and inconsistent
with how we print (e.g., X86ATTInstPrinter::printMemReference)
and parse them (e.g., X86Operand::addMemOperands).
This change shouldn't affect any tool users, but is visible to
library users or out-of-tree tablegen backends: this causes
MCOperandInfo for the segment op to have an RC instead of "unknown",
and TII::getRegClass to actually return something. As the registers
are reserved and no vregs of the class ever created, that shouldn't
change anything.
No test change; no suspicious getRegClass() in X86 and CodeGen.
llvm-svn: 271559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Testing for specific CPUs has a number of problems, better use subtarget
features:
- When some tweak is added for a specific CPU it is often desirable for
the next version of that CPU as well, yet we often forget to add it.
- It is hard to keep track of checks scattered around the target code;
Declaring all target specifics together with the CPU in the tablegen
file is a clear representation.
- Subtarget features can be tweaked from the command line.
To discourage people from using CPU checks in the future I removed the
isCortexXX(), isCyclone(), ... functions. I added an getProcFamily()
function for exceptional circumstances but made it clear in the comment
that usage is discouraged.
Reformat feature list in AArch64.td to have 1 feature per line in
alphabetical order to simplify merging and sorting for out of tree
tweaks.
No functional change intended.
Differential Revision: http://reviews.llvm.org/D20762
llvm-svn: 271555
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In PR29973 Sanjay Patel reported an assertion failure when a certain
loop was optimized, for a target without SSE2 support. It turned out
this was because of the AVG pattern detection introduced in rL253952.
Prevent the assertion failure by bailing out early in
`detectAVGPattern()`, if the target does not support SSE2.
Also add a minimized test case.
Reviewers: congh, eli.friedman, spatel
Subscribers: emaste, llvm-commits
Differential Revision: http://reviews.llvm.org/D20905
llvm-svn: 271548
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the target requests it, use emptry spaces in the fixed and
callee-save stack area to allocate local stack objects.
AArch64: Change last callee-save reg stack object alignment instead of
size to leave a gap to take advantage of above change.
Reviewers: t.p.northover, qcolombet, MatzeB
Subscribers: rengolin, mcrosier, llvm-commits, aemerson
Differential Revision: http://reviews.llvm.org/D20220
llvm-svn: 271527
|
| |
|
|
|
|
|
|
| |
Handle it locally instead of having the target-independent pass deal
with it. The generic pass does not preserve implicit uses, which may
be necessary.
llvm-svn: 271520
|
| |
|
|
| |
llvm-svn: 271519
|
| |
|
|
|
|
|
|
|
|
|
|
| |
f32/f64 to i32 with generic IR (llvm)
This patch removes the llvm intrinsics (V)CVTTPS2DQ and VCVTTPD2DQ truncation (round to zero) conversions and auto-upgrades to FP_TO_SINT calls instead.
Note: I looked at updating CVTTPD2DQ as well but this still requires a lot more work to correctly lower.
Differential Revision: http://reviews.llvm.org/D20860
llvm-svn: 271510
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20865
llvm-svn: 271508
|
| |
|
|
| |
llvm-svn: 271486
|
| |
|
|
|
|
|
|
| |
supported. VMOVNTDQ is available with AVX1.
We were getting this right for v4i64 but not the other integer types.
llvm-svn: 271482
|
| |
|
|
|
|
|
|
| |
I'm not sure why this was missing for so long.
This also exposed that we were picking floating point 256-bit VMOVNTPS for some integer types in normal isel for AVX1 even though VMOVNTDQ is available. In practice it doesn't matter due to the execution dependency fix pass, but it required extra isel patterns. Fixing that in a follow up commit.
llvm-svn: 271481
|
| |
|
|
| |
llvm-svn: 271480
|
| |
|
|
|
|
| |
unused.
llvm-svn: 271479
|
| |
|
|
|
|
|
|
| |
intrinsics instead.
The intrinsics will be autoupgraded to the same generic masked loads.
llvm-svn: 271478
|
| |
|
|
|
|
|
| |
This fixes some verifier errors when trackLivenessAfterRegAlloc is
enabled.
llvm-svn: 271446
|
| |
|
|
|
|
|
| |
This saves an additional run of the DominatorTree and
MachineLoopInfo
llvm-svn: 271444
|
| |
|
|
| |
llvm-svn: 271437
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Fix PR27943 "Bad machine code: Using an undefined physical register".
SUBFC8 implicitly defines the CR0 register, but this was omitted in
the instruction definition.
Patch by Jameson Nash <jameson@juliacomputing.com>
Reviewers: hfinkel
Differential Revision: http://reviews.llvm.org/D20802
llvm-svn: 271425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adding LLVM back-end support to two intrinsics dealing with bit scan: _bit_scan_forward and _bit_scan_reverse.
Their functionality is as described in Intel intrinsics guide:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_bit_scan_forward&expand=371,370
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_bit_scan_reverse&expand=371,370
Commit on behalf of Omer Paparo Bivas
Differential Revision: http://reviews.llvm.org/D19915
llvm-svn: 271386
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds an additional matcher to select UBFX(..) from SRL(AND(..)) in
ARMISelDAGToDAG to help with code size.
Patch by David Green.
Differential Revision: http://reviews.llvm.org/D20667
llvm-svn: 271384
|
| |
|
|
|
|
|
|
| |
Passing an empty struct as a function call argument is now supported.
unit tests for various scenarios added.
llvm-svn: 271374
|
| |
|
|
|
|
|
|
| |
generic masked load intrinsics instead."
Looks like something isn't quite right still. Also forgot to move the test cases to an autoupgrade test.
llvm-svn: 271363
|
| |
|
|
|
|
|
|
| |
intrinsics instead.
The intrinsics will be autoupgraded to the same generic masked loads.
llvm-svn: 271362
|
| |
|
|
|
|
|
|
| |
falsely marking whole 32 bit register as live.
Differential Revision: http://reviews.llvm.org/D20649
llvm-svn: 271341
|
| |
|
|
|
|
|
| |
Physregs have no associated register class, do not attempt to modify it
in Thumb2InstrInfo::storeRegToStackSlot()/loadFromStackSlot().
llvm-svn: 271339
|
| |
|
|
|
|
|
|
| |
A constant pool holding the address of a variable in equivalent to
a got entry. It produces exactly the same instruction sequence as a
got use and unlike a got use this is not uniqued by the linker.
llvm-svn: 271311
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enforce compact branch register restrictions such as the use of the zero
register, both operands being the same register. Emit clear error in such
cases as the issue is subtle.
For bovc and bnvc, silently fixup such cases when emitting objects directly,
like LLVM started doing in rL269899.
Reviewers: vkalintiris, dsanders
Differential Review: http://reviews.llvm.org/D20475
llvm-svn: 271301
|
| |
|
|
|
|
| |
Also return a single StringRef instead of building a string.
llvm-svn: 271296
|
| |
|
|
|
|
| |
Now this code path knows about position independent executables.
llvm-svn: 271290
|
| |
|
|
|
|
|
| |
The code in HexagonExpandCondsets.cpp does not handle those cases at the
moment.
llvm-svn: 271281
|
| |
|
|
|
|
|
|
|
|
| |
Introduced in r271244, this is probably undefined behaviour and asserts when
compiled with Visual C++ debug mode.
On further note, the loop is quadratic with regard to the number of successors
since removeSuccessor is linear and could probably be modified to linear time.
llvm-svn: 271278
|
| |
|
|
|
|
|
|
|
|
| |
Added support to map intrinsics
__builtin_arm_{ldc,ldcl,ldc2,ldc2l,stc,stcl,stc2,stc2l}
to their ARM instructions.
Differential Revision: http://reviews.llvm.org/D20564
llvm-svn: 271271
|
| |
|
|
|
|
| |
Added patterns for (V)CVTDQ2PD -> 2f64 loading from a 64-bit source.
llvm-svn: 271269
|
| |
|
|
|
|
|
|
|
|
|
| |
beqc and bnec cannot have $rs == $rt. Inhibit compact branch creation
if that would occur.
Reviewers: vkalintiris, dsanders
Differential Revision: http://reviews.llvm.org/D20624
llvm-svn: 271260
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20788
llvm-svn: 271255
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20780
llvm-svn: 271254
|
| |
|
|
|
|
|
|
| |
store intrinsics instead.
The intrinsics will be autoupgraded to the same generic masked stores.
llvm-svn: 271245
|
| |
|
|
|
|
|
|
|
|
|
| |
This adds support to the backed to actually support SjLj EH as an exception
model. This is *NOT* the default model, and requires explicitly opting into it
from the frontend. GCC supports this model and for MinGW can still be enabled
via the `--using-sjlj-exceptions` options.
Addresses PR27749!
llvm-svn: 271244
|
| |
|
|
|
|
| |
them. Auto upgrade to native unaligned store instructions.
llvm-svn: 271236
|
| |
|
|
| |
llvm-svn: 271229
|
| |
|
|
|
|
|
|
|
|
|
| |
The exit-on-error flag is necessary to avoid some assertions/unreachables. We
can get past them by creating a few dummy nodes.
Fixes PR27768, PR27769.
Differential Revision: http://reviews.llvm.org/D20726
llvm-svn: 271200
|
| |
|
|
| |
llvm-svn: 271160
|