| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We will be able to handle this case much better once the hazard recognizer
is finished, but this conservative implementation fixes a hang with the piglit
test:
spec/arb_arrays_of_arrays/execution/sampler/fs-nested-struct-arrays-nonconst-nested-arra
Reviewers: arsenm, nhaehnle
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18988
llvm-svn: 266105
|
| |
|
|
|
|
|
|
|
|
| |
This helps clean up some of the mess when expanding unaligned 64-bit
loads when changed to be promote to v2i32, and fixes situations
where or x, 0 was emitted after splitting 64-bit ors during moveToVALU.
I think this could be a generic combine but I'm not sure.
llvm-svn: 266104
|
| |
|
|
|
|
| |
This time it should also pass the gtests
llvm-svn: 266103
|
| |
|
|
|
|
|
|
|
|
|
| |
Add a check to catch violations. ~60 tests were broken and prevented
this change to be committed. Adrian and I (thanks Adrian!) went
through them in the last week or so updating. The check can be
done more efficiently but I'd still like to get this in ASAP to
avoid more broken tests to be checked in (if any).
PR: 27101
llvm-svn: 266102
|
| |
|
|
|
|
|
| |
This mimics the version in MathExtras.h which isn't testing for a
specific mask size.
llvm-svn: 266101
|
| |
|
|
|
|
|
|
|
|
|
| |
This code was specific to vector operations with scalar operands:
all the opcodes in FoldValue (via FoldConstantArithmetic) can't
match those criteria.
Replace it with an assert if that ever changes: at that point,
we might need to add back a splat BUILD_VECTOR.
llvm-svn: 266100
|
| |
|
|
|
|
| |
Following up to a similar fix in MergeFunctions: r266022. This patch keeps both in sync, it would be nice to not have to do this. It doesn't look like there's an easy way to test this code directly at the moment: AFAICT all currect uses of isSameOperationAs are looking at instructions deep inside a function. IndVarSimplify/pr24952.ll and InstMerge/st_sink_* look at alloca inadvertently but are brittle tests.
llvm-svn: 266099
|
| |
|
|
|
|
| |
Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor simplifications and code sharing.
llvm-svn: 266098
|
| |
|
|
| |
llvm-svn: 266097
|
| |
|
|
| |
llvm-svn: 266096
|
| |
|
|
| |
llvm-svn: 266095
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these. So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute). So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.
llvm-svn: 266093
|
| |
|
|
|
|
| |
this test ever succeeded on OS X.
llvm-svn: 266092
|
| |
|
|
| |
llvm-svn: 266091
|
| |
|
|
| |
llvm-svn: 266090
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
addAncestorsAsVirtualDirs("<stdin>") quickly returns without doing work
because "<stdin>" has no parent_path. This violates the expectation
that a subsequent call to getDirectoryFromFile("<stdin>") would succeed.
Instead, it fails because it uses the "." if the file has no path
component.
Fix this by keeping the behavior between addAncestorsAsVirtualDirs and
getDirectoryFromFile symmetric.
llvm-svn: 266089
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Under certain circumstances, multi-level breaks (or what is understood by
the control flow passes as such) could be miscompiled in a way that causes
infinite loops, by emitting incorrect control flow intrinsics.
This fixes a hang in
dEQP-GLES3.functional.shaders.loops.while_dynamic_iterations.conditional_continue_vertex
Reviewers: arsenm, tstellarAMD
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18967
llvm-svn: 266088
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
We used checks to minimize the number of remarks we present to a user
but these checks can become expensive, especially since all wrapping
assumptions are emitted separately. Because there is not benefit for a
"headless" run we put these checks under a command line flag. Thus, if
the flag is not given we will emit "non-effective" remarks, e.g.,
duplicates and revert to the old behaviour if it is given. As this
also changes the internal representation of some sets we set the flag
by default for our unit tests.
llvm-svn: 266087
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a resubmittion of 263158 change.
This patch fixes the problem which occurs when loop-vectorize tries to use @llvm.masked.load/store intrinsic for a non-default addrspace pointer. It fails with "Calling a function with a bad signature!" assertion in CallInst constructor because it tries to pass a non-default addrspace pointer to the pointer argument which has default addrspace.
The fix is to add pointer type as another overloaded type to @llvm.masked.load/store intrinsics.
Reviewed By: reames
Differential Revision: http://reviews.llvm.org/D17270
llvm-svn: 266086
|
| |
|
|
| |
llvm-svn: 266085
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In getUnderlyingObjectsForInstr(): Don't give up on instructions with
multiple MMOs, instead look through all the MMOs and if they all meet
the conservative criteria previously used for single MMO instructions,
then return all of the underlying objects derived from the MMOs.
The change to ScheduleDAGInstrs::buildSchedGraph() is needed to avoid
the case where multiple underlying objects are present and are related
in such a way that successive iterations of the loop end up adding a
dependency from an instruction to itself.
Reviewers: atrick, hfinkel
Subscribers: MatzeB, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18093
llvm-svn: 266084
|
| |
|
|
|
|
| |
test/CodeGenOpenCL/address-spaces-conversions.cl.
llvm-svn: 266083
|
| |
|
|
|
|
| |
Adds a blank line.
llvm-svn: 266082
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch enables assembler support for .set arch=octeon.
It will fix issues with inline assembler when this directive is used.
Patch by Strahinja Petrovic.
Differential Revision: http://reviews.llvm.org/D18548
llvm-svn: 266081
|
| |
|
|
|
|
|
|
| |
We need to handle the case when handler is NULL in dispatch_source_set_cancel_handler and similar interceptors.
Differential Revision: http://reviews.llvm.org/D18968
llvm-svn: 266080
|
| |
|
|
|
|
| |
vtables_blacklist into the Misc folder; NFC, this simply cleans up the generated solution so that these targets don't live in the root folder of the IDE.
llvm-svn: 266079
|
| |
|
|
|
|
| |
simply cleans up the generated solution so that these targets don't live in the root folder of the IDE.
llvm-svn: 266078
|
| |
|
|
| |
llvm-svn: 266077
|
| |
|
|
|
|
| |
We were not testing that we handle addends in here.
llvm-svn: 266076
|
| |
|
|
| |
llvm-svn: 266075
|
| |
|
|
|
|
|
| |
These are different than atomicrmw add 1 because they have
an additional input value to clamp the result.
llvm-svn: 266074
|
| |
|
|
| |
llvm-svn: 266073
|
| |
|
|
|
|
|
| |
this test was unintentionally XFAILed due to a change in the behavior of the expectedFailure
decorator. Fix that. Also, mark the test as debug-info independent while I'm in there.
llvm-svn: 266072
|
| |
|
|
|
|
|
|
| |
When the memory vectorizer is enabled, these tests break.
These tests don't really care about the memory instructions,
and it's easier to write check lines with the unmerged loads.
llvm-svn: 266071
|
| |
|
|
| |
llvm-svn: 266070
|
| |
|
|
|
|
|
|
| |
Utilizing the record option for assumptions we can simplify the wrapping
assumption generation a lot. Additionally, we can now report locations
together with wrapping assumptions, though they might not be accurate yet.
llvm-svn: 266069
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are three reasons why we want to record assumptions first before we
add them to the assumed/invalid context:
1) If the SCoP is not profitable or otherwise invalid without the
assumed/invalid context we do not have to compute it.
2) Information about the context are gathered rather late in the SCoP
construction (basically after we know all parameters), thus the user
might see overly complicated assumptions to be taken while they would
have been simplified later on.
3) Currently we cannot take assumptions at any point but have to wait,
e.g., for the domain generation to finish. This makes wrapping
assumptions much more complicated as they need to be and it will
have a similar effect on "signed-unsigned" assumptions later.
llvm-svn: 266068
|
| |
|
|
|
|
|
| |
The test changes to put _gp* in the .got section matches what both bfd
and gold do.
llvm-svn: 266067
|
| |
|
|
| |
llvm-svn: 266066
|
| |
|
|
| |
llvm-svn: 266065
|
| |
|
|
| |
llvm-svn: 266064
|
| |
|
|
|
|
|
|
|
| |
The _gp* family of symbols is defined as an offset in .got, and it is
not at all clear what should happen when .got is not defined.
This will allow some simplifications on how these symbols are handled.
llvm-svn: 266063
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They broke the msan bot.
Original message:
Add __atomic_* lowering to AtomicExpandPass.
AtomicExpandPass can now lower atomic load, atomic store, atomicrmw,and
cmpxchg instructions to __atomic_* library calls, when the target
doesn't support atomics of a given size.
This is the first step towards moving all atomic lowering from clang
into llvm. When all is done, the behavior of __sync_* builtins,
__atomic_* builtins, and C11 atomics will be unified.
Previously LLVM would pass everything through to the ISelLowering
code. There, unsupported atomic instructions would turn into __sync_*
library calls. Because of that behavior, Clang currently avoids emitting
llvm IR atomic instructions when this would happen, and emits __atomic_*
library functions itself, in the frontend.
This change makes LLVM able to emit __atomic_* libcalls, and thus will
eventually allow clang to depend on LLVM to do the right thing.
It is advantageous to do the new lowering to atomic libcalls in
AtomicExpandPass, before ISel time, because it's important that all
atomic operations for a given size either lower to __atomic_*
libcalls (which may use locks), or native instructions which won't. No
mixing and matching.
At the moment, this code is enabled only for SPARC, as a
demonstration. The next commit will expand support to all of the other
targets.
Differential Revision: http://reviews.llvm.org/D18200
llvm-svn: 266062
|
| |
|
|
|
|
|
|
| |
This reverts commit r266055.
ps4-buildslave2 is highlighting a failure.
llvm-svn: 266061
|
| |
|
|
|
|
|
|
|
|
|
|
| |
On z13, if eliminateFrameIndex() chooses LE (and not LEY), immediately
transform that LE to LDE32 to avoid partial register dependencies.
LEY should be generally preferred for big offsets over an expansion
into LAY + LDE32.
Reviewed by Ulrich Weigand.
llvm-svn: 266060
|
| |
|
|
| |
llvm-svn: 266059
|
| |
|
|
|
|
|
| |
the process info packet is slow, and sometimes it does not arrive on time when run on the android
emulator.
llvm-svn: 266058
|
| |
|
|
| |
llvm-svn: 266057
|
| |
|
|
|
|
|
|
|
|
| |
The linear clause declares one or more list items to be private to a SIMD lane and to have a linear relationship with respect to the iteration space of a loop.
'linear' '(' <linear-list> [ ':' <linear-step> ] ')'
When a linear-step expression is specified in a linear clause it must be
either a constant integer expression or an integer-typed parameter that is specified in a uniform clause on the directive.
The special this pointer can be used as if was one of the arguments to the function in any of the linear, aligned, or uniform clauses.
llvm-svn: 266056
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Alias 'jic $reg, 0' to 'jrc $reg' and 'jialc $reg, 0' to 'jalrc $reg' like
binutils.
Reviewers: dsanders
Differential Revision: http://reviews.llvm.org/D18856
llvm-svn: 266055
|