| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
| |
start with the binary operator NOT (~).
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4158
llvm-svn: 211163
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Examples:
and $2, 4 <=> andi $2, $2, 4
or $2, 4 <=> ori $2, $2, 4
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D4155
llvm-svn: 211161
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added negative test case so that we can be sure we handle erroneous situations
while parsing the .cpsetup directive.
Reviewers: dsanders
Reviewed By: dsanders
Differential Revision: http://reviews.llvm.org/D3681
llvm-svn: 211160
|
| |
|
|
|
|
|
| |
v2: Use capitalized variable name
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211159
|
| |
|
|
|
|
|
| |
v2: use C++ style comment
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211158
|
| |
|
|
|
|
|
| |
v2: Use c++ style comment
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
llvm-svn: 211157
|
| |
|
|
| |
llvm-svn: 211156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It looks like there are two versions of LowerCallTo here: the
SelectionDAGBuilder one is designed to operate on LLVM IR, and the
TargetLowering one in the case where everything is at DAG level.
Previously, only the SelectionDAGBuilder variant could handle demoting
an impossible return to sret semantics (before delegating to the
TargetLowering version), but this functionality is also useful for
certain libcalls (e.g. 128-bit operations on 32-bit x86). So this
commit moves the sret handling down a level.
rdar://problem/17242889
llvm-svn: 211155
|
| |
|
|
|
|
|
|
| |
This reverts commit cccba093090d127e0b6d17473b14c264c14c5259.
It causes build breakage.
llvm-svn: 211146
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Provides an abstraction for a random number generator (RNG) that produces a stream of pseudo-random numbers.
The current implementation uses C++11 facilities and is therefore not cryptographically secure.
The RNG is salted with the text of the current command line invocation.
In addition, a user may specify a seed (reproducible builds).
In clang, the seed can be set via
-frandom-seed=X
In the back end, the seed can be set via
-rng-seed=X
This is the llvm part of the patch.
clang part: D3391
Reviewers: ahomescu, rinon, nicholas, jfb
Reviewed By: jfb
Subscribers: jfb, perl
Differential Revision: http://reviews.llvm.org/D3390
llvm-svn: 211145
|
| |
|
|
|
|
|
|
|
| |
ReconstructShuffle() may wrongly creat a CONCAT_VECTOR trying to
concat 2 of v2i32 into v4i16. This commit is to fix this issue and
try to generate UZP1 instead of lots of MOV and INS.
Patch is initalized by Kevin Qin, and refactored by Tim Northover.
llvm-svn: 211144
|
| |
|
|
| |
llvm-svn: 211141
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch is a follow up to r211040 & r211052. Rather than bailing out of fast
isel this patch will generate an alternate instruction (movabsq) instead of the
leaq. While this will always have enough room to handle the 64 bit displacment
it is generally over kill for internal symbols (most displacements will be
within 32 bits) but since we have no way of communicating the code model to the
the assmebler in order to avoid flagging an absolute leal/leaq as illegal when
using a symbolic displacement.
llvm-svn: 211130
|
| |
|
|
|
|
|
|
|
| |
This optimizes predicates for certain compares, such as fcmp oeq %x, %x to
fcmp ord %x, %x. The latter one is more efficient to generate.
The same optimization is applied to conditional branches.
llvm-svn: 211126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pattern loses some of its usefulness when the mutex type is
statically polymorphic as opposed to runtime polymorphic, as
swapping out the mutex type requires changing a significant number
of function parameters, and templatizing the function parameter
requires the methods to be defined in the headers.
Furthermore, if LLVM is compiled with threads disabled then there
may even be no mutex to acquire anyway, so it should not be up to
individual APIs to know whether or not acquiring a mutex is required
to use those APIs to begin with. It should be up to the user of the
API.
llvm-svn: 211125
|
| |
|
|
| |
llvm-svn: 211120
|
| |
|
|
|
|
|
| |
The OSX ranlib warns on files with no symbols, and lib/Support/WindowsError.cpp
was empty when building on non-windows.
llvm-svn: 211118
|
| |
|
|
| |
llvm-svn: 211116
|
| |
|
|
| |
llvm-svn: 211115
|
| |
|
|
| |
llvm-svn: 211110
|
| |
|
|
| |
llvm-svn: 211109
|
| |
|
|
| |
llvm-svn: 211108
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to store a value greater than or equal to the number of LDS
bytes allocated by the shader in the m0 register in order for LDS
instructions to work correctly.
We always initialize m0 at the beginning of a shader, but this register
is also used for indirect addressing offsets, so we need to
re-initialize it any time we use indirect addressing.
llvm-svn: 211107
|
| |
|
|
|
|
|
| |
Overlooked that fcmp_une uses an "or" instead of an "and" for combining the
flags.
llvm-svn: 211104
|
| |
|
|
|
|
|
|
|
| |
This patch add code to remove unreachable blocks from function
as they may cause jump threading to stuck in infinite loop.
Differential Revision: http://reviews.llvm.org/D3991
llvm-svn: 211103
|
| |
|
|
| |
llvm-svn: 211100
|
| |
|
|
| |
llvm-svn: 211097
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To make sure branches are in range, we need to do a better job of estimating
the length of an inline assembly block than "it's probably 1 instruction, who'd
write asm with more than that?".
Fortunately there's already a (highly suspect, see how many ways you can think
of to break it!) callback for this purpose, which is used by the other targets.
rdar://problem/17277590
llvm-svn: 211095
|
| |
|
|
| |
llvm-svn: 211094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
trailing zeroes.
Multiplication by an integer with a number of trailing zero bits leaves
the same number of lower bits of the result initialized to zero.
This change makes MSan take this into account in the case of multiplication by
a compile-time constant.
We don't handle the general, non-constant, case because
(a) it's not going to be cheap (computation-wise);
(b) multiplication by a partially uninitialized value in user code is
a bad idea anyway.
Constant case must be handled because it appears from LLVM optimization of a
completely valid user code, as the test case in compiler-rt demonstrates.
llvm-svn: 211092
|
| |
|
|
|
|
|
|
| |
Mimic r116632 in passing LLVM_VERSION_INFO from the Makefile build
system to the build. This improves the -version output of tools that
use llvm::cl under the configure+make system.
llvm-svn: 211091
|
| |
|
|
|
|
| |
This reads a little strangely. Add a space to clean it up.
llvm-svn: 211090
|
| |
|
|
| |
llvm-svn: 211089
|
| |
|
|
| |
llvm-svn: 211087
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 211086
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As a starting step, we only use one simple heuristic: if the sign bits
of both a and b are zero, we can prove "add a, b" do not unsigned
overflow, and thus convert it to "add nuw a, b".
Updated all affected tests and added two new tests (@zero_sign_bit and
@zero_sign_bit2) in AddOverflow.ll
Test Plan: make check-all
Reviewers: eliben, rafael, meheff, chandlerc
Reviewed By: chandlerc
Subscribers: chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D4144
llvm-svn: 211084
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
r199771 accidently broke the logic that makes sure that SROA only splits
load on byte boundaries. If such a split happens, some bits get lost
when reassembling loads of wider types, causing data corruption.
Move the width check up to reject such splits early, avoiding the
corruption. Fixes PR19250.
Patch by: Björn Steinbrink <bsteinbr@gmail.com>
llvm-svn: 211082
|
| |
|
|
|
|
|
|
|
| |
function. NFC.
Make use of helper functions to simplify the branch and compare instruction
selection in FastISel. Also add test cases for compare and conditonal branch.
llvm-svn: 211077
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
[This is resubmitting r210721, which was reverted due to suspected breakage
which turned out to be unrelated].
Some extra review comments were addressed. See D4090 and D4147 for more details.
The Clang change that produces this metadata was committed in r210667
Patch by Mark Heffernan.
llvm-svn: 211076
|
| |
|
|
|
|
|
| |
These were committed accidentally from the wrong branch before having
a review sign-off.
llvm-svn: 211072
|
| |
|
|
|
|
|
|
|
|
|
| |
These parameters are intended to serve as sort of a contract that
you cannot access the functions outside of a mutex. However, the
entire JIT class cannot be accessed outside of a mutex anyway, and
all methods acquire a lock as soon as they are entered. Since the
containing class already is not intended to be thread-safe, it only
serves to add code clutter.
llvm-svn: 211071
|
| |
|
|
| |
llvm-svn: 211069
|
| |
|
|
| |
llvm-svn: 211068
|
| |
|
|
| |
llvm-svn: 211067
|
| |
|
|
|
|
| |
This allows the mutex to be acquired in a guarded, RAII fashion.
llvm-svn: 211066
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patches allows non conversions like i1=i2; where both are global ints.
In addition, arithmetic and other things start to work since fast-isel will use
existing patterns for non fast-isel from tablegen files where applicable.
In addition i8, i16 will work in this limited context for assignment without the need
for sign extension (zero or signed). It does not matter how i8 or i16 are loaded (zero or sign extended)
since only the 8 or 16 relevant bits are used and clang will ask for sign extension before using them in
arithmetic. This is all made more complete in forthcoming patches.
for example:
int i, j=1, k=3;
void foo() {
i = j + k;
}
Keep in mind that this pass is not enabled right now and is an experimental pass
It can only be enabled with a hidden option to llvm of -mips-fast-isel.
Test Plan: Run test-suite, loadstore2.ll and I will run some executable tests.
Reviewers: dsanders
Subscribers: mcrosier
Differential Revision: http://reviews.llvm.org/D3856
llvm-svn: 211061
|
| |
|
|
|
|
|
|
|
| |
Define an intrinsic for the frontend to use and pattern match it to
the RBIT instruction.
rdar://9283021
llvm-svn: 211058
|
| |
|
|
|
|
|
|
|
| |
We already have an ARMISD node. Create an intrinsic to map to it so we can
add support for the frontend __rbit() intrinsic.
rdar://9283021
llvm-svn: 211057
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rafael opened http://llvm.org/bugs/show_bug.cgi?id=19893 to track non-optimal
code generation for forming a function address that is local to the compile
unit. The existing code was treating both local and non-local functions
identically.
This patch fixes the problem by properly identifying local functions and
generating the proper addis/addi code. I also noticed that Rafael's earlier
changes to correct the surrounding code in PPCISelLowering.cpp were also
needed for fast instruction selection in PPCFastISel.cpp, so this patch
fixes that code as well.
The existing test/CodeGen/PowerPC/func-addr.ll is modified to test the new
code generation. I've added a -O0 run line to test the fast-isel code as
well.
Tested on powerpc64[le]-unknown-linux-gnu with no regressions.
llvm-svn: 211056
|
| |
|
|
|
|
| |
and query the base target machine implementation for it.
llvm-svn: 211055
|