| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Currently this is to mainly to prevent scalarization of integer division by constants.
Differential Revision: http://reviews.llvm.org/D18307
llvm-svn: 264511
|
| |
|
|
|
|
|
|
| |
multiplies.
Only pre-AVX512BW targets need to split v32i8 vectors.
llvm-svn: 264509
|
| |
|
|
|
|
|
|
|
| |
The minnum and maxnum intrinsics get lowered to libcalls which
invalidates the CTR optimization.
This fixes PR27083.
llvm-svn: 264508
|
| |
|
|
|
|
| |
LowerMul v32i8 on AVX2 needs to split the 256-bit sources to allow sign-extension back to v16i16 to occur. Since this is basically the same as Lower256IntArith we simplify by using that here instead.
llvm-svn: 264506
|
| |
|
|
| |
llvm-svn: 264505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sign, negate, parity, shift/rotate, mul10
This change implements the following vector operations:
- vclzlsbb vctzlsbb vctzb vctzd vctzh vctzw
- vextsb2w vextsh2w vextsb2d vextsh2d vextsw2d
- vnegd vnegw
- vprtybd vprtybq vprtybw
- vbpermd vpermr
- vrlwnm vrlwmi vrldnm vrldmi vslv vsrv
- vmul10cuq vmul10uq vmul10ecuq vmul10euq
28 instructions
Thanks Nemanja, Kit for invaluable hints and discussion!
Reviewers: hal, nemanja, kbarton, tjablin, amehsan
Phabricator: http://reviews.llvm.org/D15887
llvm-svn: 264504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that the summary contains the full reference/call graph, we can
replace the existing function importer that loads and inspect the IR
to iteratively walk the call graph by a traversal based purely on the
summary information. Decouple the actual importing decision from any
IR manipulation.
Reviewers: tejohnson
Subscribers: llvm-commits, joker.eph
Differential Revision: http://reviews.llvm.org/D18343
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264503
|
| |
|
|
|
|
|
| |
It now return the map instead of an iterator.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264489
|
| |
|
|
|
|
| |
As discussed on the llvm-commits thread for r264467.
llvm-svn: 264479
|
| |
|
|
|
|
|
|
|
|
|
| |
the rename operation on 3 error conditions of ReplaceFileW() that it was
previously bailing out on.
Patch by Douglas Yung!
Differential Revision: http://reviews.llvm.org/D17903
llvm-svn: 264477
|
| |
|
|
|
|
| |
ErrorOr<...>.
llvm-svn: 264473
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A release fence acts as a publication barrier for stores within the current thread to become visible to other threads which might observe the release fence. It does not require the current thread to observe stores performed on other threads. As a result, we can allow store-load and load-load forwarding across a release fence.
We choose to be much more conservative about stores. In theory, nothing prevents us from shifting a store from after a release fence to before it, and then eliminating the preceeding (previously fenced) store. Doing this without actually moving the second store is likely also legal, but we chose to be conservative at this time.
The LangRef indicates only atomic loads and stores are effected by fences. This patch chooses to be far more conservative then that.
This is the GVN companion to http://reviews.llvm.org/D11434 which applied the same logic in EarlyCSE and has been baking in tree for a while now.
Differential Revision: http://reviews.llvm.org/D11436
llvm-svn: 264472
|
| |
|
|
|
|
|
|
|
|
| |
method instead.
This is not quite a named constructor: Construction may fail, and
MachOObjectFiles are usually passed by unique_ptr anyway, so create
returns an Expected<std::unique_ptr<MachOObjectFile>>.
llvm-svn: 264469
|
| |
|
|
|
|
|
|
|
| |
We forgot to add the second machine operand to our ADJCALLSTACKDOWN,
resulting in crashes in PEI.
This fixes PR27071.
llvm-svn: 264465
|
| |
|
|
|
|
|
|
|
|
|
| |
regmasks
When encountering instructions with regmasks, instead of cleaning up all the
elements in MaybeDeadCopies map, remove only the instructions erased. By keeping
more instruction in MaybeDeadCopies, this change will expose more dead copies
across instructions with regmasks.
llvm-svn: 264462
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When merging stores in DAGCombiner, add check to ensure that no
dependenices exist that would cause the construction of a cycle in our
DAG. This may happen if one store has a data dependence on another
instruction (e.g. a load) which itself has a (chain) dependence on
another store being merged. These stores cannot be merged safely and
doing so results in a cycle that is discovered in LegalizeDAG.
This test is only done in cases where Antialias analysis is used (UseAA)
as non-AA store merge candidates will be merged logically after all
loads which have been checked to not alias.
Reviewers: ahatanak, spatel, niravd, arsenm, hfinkel, tstellarAMD, jyknight
Subscribers: llvm-commits, tberghammer, danalbert, srhines
Differential Revision: http://reviews.llvm.org/D18336
llvm-svn: 264461
|
| |
|
|
| |
llvm-svn: 264459
|
| |
|
|
|
|
| |
function always returned an empty string.
llvm-svn: 264458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This changes RS4GC to lower calls to ``@llvm.experimental.deoptimize``
to gc.statepoints wrapping ``__llvm_deoptimize``, and changes
``callsGCLeafFunction`` to recognize ``@llvm.experimental.deoptimize``
as a non GC leaf function.
I've had to hard code the ``"__llvm_deoptimize"`` name in
RewriteStatepointsForGC; since ``TargetLibraryInfo`` is available only
during codegen. This isn't without precedent in the codebase, so I'm
not overtly concerned.
llvm-svn: 264456
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a use-after-free introduced 3 years ago, in r182872 ;)
The code more or less worked because the memory that CopyMI was
pointing to happened to still be valid, but lots of tests would crash
if you ran under ASAN with the recycling allocator changes from
llvm.org/PR26808
llvm-svn: 264455
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
It is possible to have a fallthrough MBB prior to MBB placement. The original
addition of the BB would result in reordering the BB as not preceding the
successor. Because of the fallthrough nature of the BB, we could end up
executing incorrect code or even a constant pool island! Insert the spliced BB
into the same location to avoid that.
Thanks to Tim Northover for invaluable hints and Fiora for the discussion on
what may have been occurring!
llvm-svn: 264454
|
| |
|
|
|
|
| |
Helps distinguish from refs() which iterates over non-call references.
llvm-svn: 264445
|
| |
|
|
|
|
| |
Found by ASAN with the recycling allocator changes from PR26808.
llvm-svn: 264443
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're erasing MI here, but then immediately using it again inside the
`if`. This moves the erase after we're done using it.
Doing that reveals a second problem though - this case is missing a
break, so we fall through to the default and dereference MI again.
This is obviously a bug, though I don't know how to write a test that
triggers it - all we do in the error case is print some extra debug
output.
Both of these issue crash on lots of tests under ASAN with the
recycling allocator changes from PR26808 applied.
llvm-svn: 264442
|
| |
|
|
|
|
|
|
|
|
|
|
| |
64-bit, 32-bit and 16-bit move-immediate instructions are 7, 6, and 5 bytes,
respectively, whereas and/or with 8-bit immediate is only three bytes.
Since these instructions imply an additional memory read (which the CPU could
elide, but we don't think it does), restrict these patterns to minsize functions.
Differential Revision: http://reviews.llvm.org/D18374
llvm-svn: 264440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now register parameters that aren't saved to the stack or CSRs are
considered dead after the first call. Previously the debugger would show
whatever was in the register.
Fixes PR26589
Reviewers: aprantl
Differential Revision: http://reviews.llvm.org/D17211
llvm-svn: 264429
|
| |
|
|
| |
llvm-svn: 264425
|
| |
|
|
|
|
|
|
| |
The BranchUnaryRI instruction class already sets these flags.
Reviewed by Ulrich Weigand.
llvm-svn: 264411
|
| |
|
|
|
|
|
| |
This reverts commit r264409 since it failed to bootstrap:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_build/8302/
llvm-svn: 264410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimize output of MDStrings in bitcode. This emits them in big blocks
(currently 1024) in a pair of records:
- BULK_STRING_SIZES: the sizes of the strings in the block, and
- BULK_STRING_DATA: a single blob, which is the concatenation of all
the strings.
Inspired by Mehdi's similar patch, http://reviews.llvm.org/D18342, this
should (a) slightly reduce bitcode size, since there is less record
overhead, and (b) greatly improve reading speed, since blobs are super
cheap to deserialize.
I needed to add support for blobs to streaming input to get the test
suite passing.
- StreamingMemoryObject::getPointer reads ahead and returns the
address of the blob.
- To avoid a possible reallocation of StreamingMemoryObject::Bytes,
BitstreamCursor::readRecord needs to move the call to JumpToEnd
forward so that getPointer is the last bitstream operation.
llvm-svn: 264409
|
| |
|
|
| |
llvm-svn: 264408
|
| |
|
|
|
|
|
|
| |
Patch by Evgeny Stupachenko.
Differential Revision: http://reviews.llvm.org/D18202
llvm-svn: 264407
|
| |
|
|
|
|
| |
LowerShift was using the same code as Lower256IntArith to split 256-bit vectors into 2 x 128-bit vectors, so now we just call Lower256IntArith.
llvm-svn: 264403
|
| |
|
|
| |
llvm-svn: 264395
|
| |
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18456
This is a re-commit of r264387 and r264388 after fixing a typo.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264392
|
| |
|
|
|
|
|
|
| |
This reverts commit r264387.
Bots are broken in various ways, I need to take one commit at a time...
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264390
|
| |
|
|
|
|
|
|
| |
This reverts commit r264388.
Bots are broken in various ways, I need to take one commit at a time...
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264389
|
| |
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264388
|
| |
|
|
|
|
|
|
|
|
|
| |
Reviewers: silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18456
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Loading IR with debug info improves MDString::get() from 19ms to 10ms.
This is a rework of D16597 with adding an "emplace" method on the StringMap
to avoid requiring the MDString move ctor to be public.
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17920
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
StringMap ctor accepts an initialize size, but expect it to be
rounded to the next power of 2. The ctor can handle that directly
instead of expecting clients to round it. Also, since the map will
resize itself when 75% full, take this into account an initialize
a larger initial size to avoid any growth.
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18344
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These are just helpers calling their static counter part to
simplify client code.
Reviewers: tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18339
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 264382
|
| |
|
|
|
|
|
| |
Caught by inspection while working on partitioning metadata. It's nice
to produce the same bitcode if you run the compiler twice.
llvm-svn: 264381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation for MODULE_CODE_METADATA_VALUES was to enable an
-flto=thin scheme where:
1. First, one function is cherry-picked from a bitcode file.
2. Later, another function is cherry-picked.
3. Later, ...
4. Finally, the metadata needed by all the previous functions is
loaded.
This was abandoned in favour of:
1. Calculate the superset of functions needed from a Module.
2. Link all functions at once.
Delayed metadata reading no longer serves a purpose. It also adds
a few complication, since we can't count on metadata being properly
parsed when exiting the BitcodeReader. After discussing with Teresa, we
agreed to remove it.
The code that depended on this was removed/updated in r264326.
llvm-svn: 264378
|
| |
|
|
|
|
|
| |
This resolves bug 21148 by preventing promotion to
i64 induction variables.
llvm-svn: 264376
|
| |
|
|
|
|
|
|
|
| |
This is the same as r255936, with added logic for avoiding clobbering of the
red zone (PR26023).
Differential Revision: http://reviews.llvm.org/D18246
llvm-svn: 264375
|
| |
|
|
| |
llvm-svn: 264374
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Remove logic to upgrade !llvm.loop by changing the MDString tag
directly. This old logic would check (and change) arbitrary strings
that had nothing to do with loop metadata. Instead, check !llvm.loop
attachments directly, and change which strings get attached.
Rather than updating the assembly-based upgrade, drop it entirely. It
has been quite a while since we supported upgrading textual IR.
llvm-svn: 264373
|
| |
|
|
|
|
|
|
|
|
| |
This reserves an MDKind for !llvm.loop, which allows callers to avoid a
string-based lookup. I'm not sure why it was missing.
There should be no functionality change here, just a small compile-time
speedup.
llvm-svn: 264371
|
| |
|
|
|
|
|
|
|
| |
We did not have an explicit branch to the continuation BB. When the check was
hoisted, this could permit control follow to fall through into the division
trap. Add the explicit branch to the continuation basic block to ensure that
code execution is correct.
llvm-svn: 264370
|