| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, fs::rename() could fail is another process was reading the
file at the same time using fs::openFileForRead(). In most cases the user
wouldn't notice as fs::rename() will continue to retry for 2000ms. Typically
this is enough for the read to complete and a retry to succeed, but if the
disk is being it too hard then the response time might be longer than the
retry time and the rename would fail with a permission error.
Add FILE_SHARE_DELETE to the sharing flags for CreateFileW() in
fs::openFileForRead() and try ReplaceFileW() prior to MoveFileExW()
in fs::rename().
Based on an initial patch by Edd Dawson!
Differential Revision: http://reviews.llvm.org/D13647
llvm-svn: 250046
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
register belongs.
Summary: Fixes PR24915.
Reviewers: vkalintiris
Subscribers: emaste, seanbruno, llvm-commits
Differential Revision: http://reviews.llvm.org/D13533
llvm-svn: 250042
|
|
|
|
|
|
|
|
| |
changes. NFC.
Mostly tabs -> spaces and double spacing.
llvm-svn: 250041
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: vkalintiris
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13591
llvm-svn: 250040
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This removes unnecessary instructions when extracting from an undefined register
and also fixes a crash for O32 when passing undef to a double argument in
held in integer registers.
Reviewers: vkalintiris
Subscribers: llvm-commits, zoran.jovanovic, petarj
Differential Revision: http://reviews.llvm.org/D13467
llvm-svn: 250039
|
|
|
|
|
|
|
|
| |
GlobalOpt currently merges stores into the initialisers of internal,
externally_initialized globals, but should not do so as the value of the global
may change between the initialiser and any code in the module being run.
llvm-svn: 250035
|
|
|
|
|
|
|
|
|
|
|
| |
The Swift Machine Scheduler Model is incomplete. There are instructions
missing which can trigger the "incomplete machine model" abort. This was
observed when a downstream SchedMachineModel was added to the ARM
target.
Patch by Christof Douma!
llvm-svn: 250033
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C semantics force sub-int-sized values (e.g. i8, i16) to be promoted to int
type (e.g. i32) whenever arithmetic is performed on them.
For targets with native i8 or i16 operations, usually InstCombine can shrink
the arithmetic type down again. However InstCombine refuses to create illegal
types, so for targets without i8 or i16 registers, the lengthening and
shrinking remains.
Most SIMD ISAs (e.g. NEON) however support vectors of i8 or i16 even when
their scalar equivalents do not, so during vectorization it is important to
remove these lengthens and truncates when deciding the profitability of
vectorization.
The algorithm this uses starts at truncs and icmps, trawling their use-def
chains until they terminate or instructions outside the loop are found (or
unsafe instructions like inttoptr casts are found). If the use-def chains
starting from different root instructions (truncs/icmps) meet, they are
unioned. The demanded bits of each node in the graph are ORed together to form
an overall mask of the demanded bits in the entire graph. The minimum bitwidth
that graph can be truncated to is the bitwidth minus the number of leading
zeroes in the overall mask.
The intention is that this algorithm should "first do no harm", so it will
never insert extra cast instructions. This is why the use-def graphs are
unioned, so that subgraphs with different minimum bitwidths do not need casts
inserted between them.
This algorithm works hard to reduce compile time impact. DemandedBits are only
queried if there are extends of illegal types and if a truncate to an illegal
type is seen. In the general case, this results in a simple linear scan of the
instructions in the loop.
No non-noise compile time impact was seen on a clang bootstrap build.
llvm-svn: 250032
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add intrinsics for the
XSAVE instructions (XSAVE/XSAVE64/XRSTOR/XRSTOR64)
XSAVEOPT instructions (XSAVEOPT/XSAVEOPT64)
XSAVEC instructions (XSAVEC/XSAVEC64)
XSAVES instructions (XSAVES/XSAVES64/XRSTORS/XRSTORS64)
Differential Revision: http://reviews.llvm.org/D13012
llvm-svn: 250029
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
indices have the most significant bit set.
This patch fixes a problem in function 'combineX86ShuffleChain' that causes a
chain of shuffles to be wrongly folded away when the combined shuffle mask has
only one element.
We may end up with a combined shuffle mask of one element as a result of
multiple calls to function 'canWidenShuffleElements()'.
Function canWidenShuffleElements attempts to simplify a shuffle mask by widening
the size of the elements being shuffled.
For every pair of shuffle indices, function canWidenShuffleElements checks if
indices refer to adjacent elements. If all pairs refer to "adjacent" elements
then the shuffle mask is safely widened. As a consequence of widening, we end up
with a new shuffle mask which is half the size of the original shuffle mask.
The byte shuffle (pshufb) from test pr24562.ll has a mask of all SM_SentinelZero
indices. Function canWidenShuffleElements would combine each pair of
SM_SentinelZero indices into a single SM_SentinelZero index. So, in a
logarithmic number of steps (4 in this case), the pshufb mask is simplified to
a mask with only one index which is equal to SM_SentinelZero.
Before this patch, function combineX86ShuffleChain wrongly assumed that a mask
of size one is always equivalent to an identity mask. So, the entire shuffle
chain was just folded away as the combined shuffle mask was treated as a no-op
mask.
With this patch we know check if the only element of a combined shuffle mask is
SM_SentinelZero. In case, we propagate a zero vector.
Differential Revision: http://reviews.llvm.org/D13364
llvm-svn: 250027
|
|
|
|
| |
llvm-svn: 250026
|
|
|
|
|
|
|
|
|
|
| |
Summary: Unnecessary space at the beginning of LLVM_DEFINITIONS in cmake shared files can break projects that use the variable.
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13432
llvm-svn: 250025
|
|
|
|
|
|
|
|
|
| |
New instructions using floating point registers have been added, to check
that AsmParser can deal with fp regs in vector instructions.
This tests r249810.
llvm-svn: 250023
|
|
|
|
|
|
|
|
|
|
|
|
| |
This script prints a CSV of all misched models of a target when given the output of the debug output of subtarget using:
llvm-tblgen --gen-subtarget --debug-only=subtarget-emitter ...
With thanks to Dave Estes for mentioning the idea at the 2014 LLVM Developers' Meeting.
Patch by Christof Douma!
llvm-svn: 250020
|
|
|
|
|
|
|
|
|
| |
This patch also allows the -delinearize pass to delinearize expressions that do
not have an outermost SCEVAddRec expression. The SCEV::delinearize
infrastructure allowed this since r240952, but the -delinearize pass was not
updated yet.
llvm-svn: 250018
|
|
|
|
|
|
| |
instructions. This way the assembler will perform range checking. Believe this matches gas behavior.
llvm-svn: 250016
|
|
|
|
|
|
| |
%xmmX, %xmmX encoding if it would be a shorter VEX encoding.
llvm-svn: 250014
|
|
|
|
| |
llvm-svn: 250013
|
|
|
|
|
|
| |
parser will check the size.
llvm-svn: 250012
|
|
|
|
|
|
|
|
| |
arithmetic instructions with 8-bit immediates over the forms that implicitly use the ax/eax/rax.
This allows us to remove the explicit code for working around the existing priority
llvm-svn: 250011
|
|
|
|
| |
llvm-svn: 250004
|
|
|
|
| |
llvm-svn: 249999
|
|
|
|
|
|
| |
al/ax/eax/rax as a def. Probably doesn't have a functional affect since these aren't used in isel.
llvm-svn: 249994
|
|
|
|
|
|
|
|
| |
Enabled constant canonicalization for all constants.
Improved combining of constant vectors.
llvm-svn: 249993
|
|
|
|
|
|
| |
As discussed in D8690.
llvm-svn: 249990
|
|
|
|
|
|
|
|
| |
Instead mark its operand type as u8imm which will cause it to fail to match. This is more consistent with other instruction behavior.
This also fixes a bug where negative immediates below -128 were not being reported as errors.
llvm-svn: 249989
|
|
|
|
|
|
|
|
| |
Matches naming conventions for ASHR/LSHR cost tests
As discussed in D8690.
llvm-svn: 249984
|
|
|
|
|
|
|
|
| |
There are several dodgy costings due to AVX1 legalizing 256-bit integer vectors that need fixing.
As discussed in D8690.
llvm-svn: 249983
|
|
|
|
|
|
|
|
| |
There are several dodgy costings due to AVX1 legalizing 256-bit integer vectors that need fixing.
As discussed in D8690.
llvm-svn: 249981
|
|
|
|
|
|
| |
output file. While there replace type with 'auto' since there's a cast on the right side of the assignment. NFC
llvm-svn: 249980
|
|
|
|
| |
llvm-svn: 249979
|
|
|
|
|
|
|
|
| |
Enable constant folding for vector splats as well as scalars.
Enable constant canonicalization for all scalar and vector constants.
llvm-svn: 249978
|
|
|
|
|
|
| |
We now have lowering support for XOP PCOM/PCOMU instructions.
llvm-svn: 249977
|
|
|
|
|
|
|
|
| |
comparisons to XOP PCOM/PCOMU instructions.
The XOP vector integer comparisons can deal with all signed/unsigned comparison cases directly and can be easily commuted as well (D7646).
llvm-svn: 249976
|
|
|
|
|
|
| |
This is a test of the LLVM commit system. In the event of a real commit there would be some useful code changes.
llvm-svn: 249972
|
|
|
|
| |
llvm-svn: 249954
|
|
|
|
| |
llvm-svn: 249952
|
|
|
|
|
|
| |
undefined behavior. Also change it to use the same formula as the template version which I think results in less math in compiled code.
llvm-svn: 249951
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The change to use the VST function entries for lazy deserialization did
not handle the case of anonymous functions without aliases. In that case
we must fall back to scanning the function blocks as there is no VST
entry.
Reviewers: dexonsmith, joker.eph, davidxl
Subscribers: tstellarAMD, llvm-commits
Differential Revision: http://reviews.llvm.org/D13596
llvm-svn: 249947
|
|
|
|
|
|
| |
Relates to the fixes of r249811.
llvm-svn: 249946
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expandPostRAPseudo():
STX -> 2 * STD: The first STD should not have the kill flag set for the address.
SystemZElimCompare:
BRC -> BRCT conversion: Don't forget to remove the CC<use,kill> operand.
Needed to make SystemZ/asm-17.ll pass with -verify-machineinstrs, which
now runs with this flag.
Reviewed by Ulrich Weigand.
llvm-svn: 249945
|
|
|
|
| |
llvm-svn: 249944
|
|
|
|
| |
llvm-svn: 249943
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Rather than just iterating over all sections and checking whether we have relocations for them, iterate over the relocation map instead. This showed up heavily in an artificial julia benchmark that does lots of compilation. On that particular benchmark, this patch gives
~15% performance improvements. As far as I can tell the primary reason why the original
loop was so expensive is that Relocations[i] actually constructs a relocationList (allocating memory & doing lots of other unnecessary computing) if none is found.
Reviewers: lhames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D13545
llvm-svn: 249942
|
|
|
|
| |
llvm-svn: 249941
|
|
|
|
| |
llvm-svn: 249940
|
|
|
|
|
| |
FIXME: Improve llvm-symbolizer, or rename the feature "system-windows".
llvm-svn: 249937
|
|
|
|
| |
llvm-svn: 249933
|
|
|
|
|
|
| |
rdar://22983603
llvm-svn: 249927
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
llvm-svn: 249925
|