| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 237065
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9684
llvm-svn: 237063
|
| |
|
|
| |
llvm-svn: 237062
|
| |
|
|
| |
llvm-svn: 237061
|
| |
|
|
| |
llvm-svn: 237060
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The TargetRegistry is just a namespace-like class, instantiated in one
place to use a range-based for loop. Instead, expose access to the
registry via a range-based 'targets()' function instead. This makes most
uses a bit awkward/more verbose - but eventually we should just add a
range-based find_if function which will streamline these functions. I'm
happy to mkae them a bit awkward in the interim as encouragement to
improve the algorithms in time.
llvm-svn: 237059
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cleanups.
Also, change code in tablegen which printed a message and then called
"exit(1)" to use PrintFatalError, instead.
This fixes instances where an empty output file was left behind after
a failed tablegen invocation, which would confuse subsequent ninja
runs into not attempting to rebuild.
Differential Revision: http://reviews.llvm.org/D9608
llvm-svn: 237058
|
| |
|
|
|
|
| |
10 minutes to avoid buildbot timeouts
llvm-svn: 237054
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
1. llvm-as/llvm-dis tools do not check for input filename length.
2. llvm-dis does not verify the `Streamer` variable against `nullptr` properly, so the `M` variable could be uninitialized (e.g. if the input file does not exist) leading to null dref.
Patch by Lenar Safin!
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: samsonov, llvm-commits
Differential Revision: http://reviews.llvm.org/D9584
llvm-svn: 237051
|
| |
|
|
|
|
| |
comments. NFC expected
llvm-svn: 237050
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a less ambitious version of:
http://reviews.llvm.org/rL236546
because that was reverted in:
http://reviews.llvm.org/rL236600
because it caused memory corruption that wasn't related to FMF
but was actually due to making nodes with 2 operands derive from a
plain SDNode rather than a BinarySDNode.
This patch adds the minimum plumbing necessary to use IR-level
fast-math-flags (FMF) in the backend without actually using
them for anything yet. This is a follow-on to:
http://reviews.llvm.org/rL235997
...which split the existing nsw / nuw / exact flags and FMF
into their own struct.
llvm-svn: 237046
|
| |
|
|
|
|
|
|
|
| |
runOnCountable() allowed the caller to call on a loop without a
predictable backedge-taken count. Change the code so that only loops
with computable backdge-count can call this function, in order to catch
abuses.
llvm-svn: 237044
|
| |
|
|
|
|
| |
DFSan-based mutator, but instead of relying on taint tracking, try to find the data directly in the input. More (logic and comments) to go.
llvm-svn: 237043
|
| |
|
|
| |
llvm-svn: 237042
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9512
llvm-svn: 237014
|
| |
|
|
| |
llvm-svn: 237013
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vector of pointers
Summary:
In RewriteStatepointsForGC pass, we create a gc_relocate intrinsic for
each relocated pointer, and the gc_relocate has the same type with the
pointer. During the creation of gc_relocate intrinsic, llvm requires to
mangle its type. However, llvm does not support mangling of all possible
types. RewriteStatepointsForGC will hit an assertion failure when it
tries to create a gc_relocate for pointer to vector of pointers because
mangling for vector of pointers is not supported.
This patch changes the way RewriteStatepointsForGC pass creates
gc_relocate. For each relocated pointer, we erase the type of pointers
and create an unified gc_relocate of type i8 addrspace(1)*. Then a
bitcast is inserted to convert the gc_relocate to the correct type. In
this way, gc_relocate does not need to deal with different types of
pointers and the unsupported type mangling is no longer a problem. This
change would also ease further merge when LLVM erases types of pointers
and introduces an unified pointer type.
Some minor changes are also introduced to gc_relocate related part in
InstCombineCalls, CodeGenPrepare, and Verifier accordingly.
Patch by Chen Li!
Reviewers: reames, AndyAyers, sanjoy
Reviewed By: sanjoy
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9592
llvm-svn: 237009
|
| |
|
|
| |
llvm-svn: 237008
|
| |
|
|
|
|
|
|
| |
This makes it easier to update in place instructions with tied operands.
Differential Revision: http://reviews.llvm.org/D9231
llvm-svn: 237005
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r235215 adds support for f16 to be considered as a load/store type and
promote f16 operations to f32.
This patch has miscellaneous fixes for the X86 backend so all f16
operations are handled:
1. Set loadextaction for f16 vectors to expand.
2. Handle FP_EXTEND in a switch statement when handling v2f32
3. Do not fold (FP_TO_SINT (load f16)) into FP_TO_INT*_IN_MEM or
(store (SINT_TO_FP )) to a FILD.
Tests included.
Reviewers: ab, srhines, delena
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9092
llvm-svn: 237004
|
| |
|
|
|
|
|
|
|
|
|
| |
ValueTracking.
This matching functionality is useful in more than just InstCombine, so
make it available in ValueTracking.
NFC.
llvm-svn: 236998
|
| |
|
|
| |
llvm-svn: 236991
|
| |
|
|
|
|
| |
previously causing a warning with MSVC about a compiler-generated local variable because TargetRegistry::begin() and end() are static member functions. NFC.
llvm-svn: 236990
|
| |
|
|
|
|
| |
converted to 64 bits (was 64-bit shift intended?); NFC
llvm-svn: 236987
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now it's much easier to follow what's happening in this test.
Also removed some unused metadata entries.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9601
llvm-svn: 236981
|
| |
|
|
|
|
|
|
| |
from i8 to i32 according to the Intel Spec
by Igor Breger (igor.breger@intel.com)
llvm-svn: 236979
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As far as I understand the entire point of this example is to show that
if noalias is not a superset/equal to the alias.scope list on a scope
domain then load could reference locations that the store is not known
to not-alias i.e may alias.
Reviewers: hfinkel
Reviewed By: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D9598
llvm-svn: 236977
|
| |
|
|
|
|
|
|
|
|
| |
The QPX single-precision load/store intrinsics have implied
truncation/extension from/to the declared value type of <4 x double> to the
memory type of <4 x float>. When we can prove the alignment of the pointer
argument, and thus replace the intrinsic with a regular load or store, we need
to load or store the correct data type (<4 x float>) instead of (<4 x double>).
llvm-svn: 236973
|
| |
|
|
| |
llvm-svn: 236972
|
| |
|
|
|
|
|
|
| |
{add/sub/mul/div/} x {ps/pd} x {128/256} 2. max/min with sae
By Asaf Badouh (asaf.badouh@intel.com)
llvm-svn: 236971
|
| |
|
|
| |
llvm-svn: 236970
|
| |
|
|
|
|
|
|
| |
Use the element type instead of the aggregate type.
Differential Revision: http://reviews.llvm.org/D9591
llvm-svn: 236969
|
| |
|
|
|
|
|
|
| |
Use the element type instead of the aggregate type.
Differential Revision: http://reviews.llvm.org/D9596
llvm-svn: 236968
|
| |
|
|
| |
llvm-svn: 236955
|
| |
|
|
|
|
|
|
| |
then the folded type.
Found when testing with llvm-stress on i686 targets.
llvm-svn: 236954
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Second attempt; instead of using a named local variable, passing
arguments directly to `createSanitizerCtorAndInitFunctions` worked
on Windows.
Reviewers: kcc, samsonov
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D8780
llvm-svn: 236951
|
| |
|
|
| |
llvm-svn: 236947
|
| |
|
|
|
|
|
|
| |
warning: enumeral and non-enumeral type in conditional expression
Cast the 0 to the appropriate type. NFC. Identified by GCC 4.9.2
llvm-svn: 236942
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes:
- Add "isl/" as a system library prefix. Even though isl is regularly
imported into polly, it is still used like an external library.
- Add "json/" as a system library prefix. Polly uses json-cpp as external
library.
- Distinguish between llvm and subproject libraries. Always sort subprojects
before LLVM. This was already the case with clang, as 'clang' comes before
'llvm', but we also want 'polly' to be sorted before 'llvm'.
The sorting of headers that are not part of Polly or isl remains unchanged.
llvm-svn: 236929
|
| |
|
|
| |
llvm-svn: 236928
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug showed up as a compile-time assertion failure:
Assertion `NumBits >= MIN_INT_BITS && "bitwidth too small"' failed
when building msan tests on x86-64.
Prior to r236850, this bug was masked due to a bogus alignment check,
which also accidentally rejected non-byte-sized accesses. Afterwards,
an invalid ElementSizeBytes == 0 got further into the function, and
triggered the assertion failure.
It would probably be a good idea to allow it to handle merging stores
of unusual widths as well, but for now, to un-break it, I'm just
making the minimal fix.
Differential Revision: http://reviews.llvm.org/D9626
llvm-svn: 236927
|
| |
|
|
|
|
|
|
|
| |
This is used to determine whether or not to CSE physical register
defs.
Differential Revision: http://reviews.llvm.org/D9472
llvm-svn: 236923
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When emitting something like 'add x, 1000' if we remat the 1000 then we should be able to
mark the vreg containing 1000 as killed. Given that we go bottom up in fast-isel, a later
use of 1000 will be higher up in the BB and won't kill it, or be impacted by the lower kill.
However, rematerialised constant expressions aren't generated bottom up. The local value save area
grows downwards. This means that if you remat 2 constant expressions which both use 1000 then the
first will kill it, then the second, which is *lower* in the BB will read a killed register.
This is the case in the attached test where the 2 GEPs both need to generate 'add x, 6680' for the constant offset.
Note that this commit only makes kill flag generation conservative. There's nothing else obviously wrong with
the local value save area growing downwards, and in fact it needs to for handling arbitrarily complex constant expressions.
However, it would be nice if there was a solution which would let us generate more accurate kill flags, or just kill flags completely.
llvm-svn: 236922
|
| |
|
|
| |
llvm-svn: 236921
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Author: dblaikie
Date: Fri May 8 17:47:50 2015
New Revision: 236912
URL: http://llvm.org/viewvc/llvm-project?rev=236912&view=rev
Log:
[opaque pointer type] Cleanup a few references to pointee types using nearby non-pointee types of the same value
& cleanup a convoluted return expression while I'm here
llvm-svn: 236919
|
| |
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D9611
Reviewed by: rengolin
llvm-svn: 236918
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
non-aliasing distinct objects
The code that builds the dependence graph assumes that two PseudoSourceValues
don't alias. In a tail calling function two FixedStackObjects might refer to the
same location. Worse 'immutable' fixed stack objects like function arguments are
not immutable and will be clobbered.
Change this so that a load from a FixedStackObject is not invariant in a tail
calling function and don't return a PseudoSourceValue for an instruction in tail
calling functions when building the dependence graph so that we handle function
arguments conservatively.
Fix for PR23459.
rdar://20740035
llvm-svn: 236916
|
| |
|
|
|
|
|
|
| |
non-pointee types of the same value
& cleanup a convoluted return expression while I'm here
llvm-svn: 236912
|
| |
|
|
| |
llvm-svn: 236909
|
| |
|
|
|
|
| |
LLVM_USE_SANITIZE_COVERAGE; in lib/Fuzzer try to reload the corpus to pick up new units from other processes
llvm-svn: 236906
|