| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
IDs from dwp input files
If you're building dwps from other dwps, it can be hard to track down a
duplicate CU ID if it comes from two compilations of the same file in
different modes, etc. By including the .dwo path (which is hopefully
more unique than the file path) it can help track down where the
duplicates came from.
llvm-svn: 264520
|
| |
|
|
|
|
| |
Correct splitting of v8i32 vectors into v4i32 vectors to prevent scalarization
llvm-svn: 264517
|
| |
|
|
|
|
|
|
| |
Correct splitting of v16i16 vectors into v8i16 vectors to prevent scalarization
Differential Revision: http://reviews.llvm.org/D18307
llvm-svn: 264512
|
| |
|
|
|
|
|
|
| |
Currently this is to mainly to prevent scalarization of integer division by constants.
Differential Revision: http://reviews.llvm.org/D18307
llvm-svn: 264511
|
| |
|
|
| |
llvm-svn: 264510
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Add all 256-bit vector tests.
Added AVX512F/AVX512BW test targets.
Renamed tests something more meaningful.
llvm-svn: 264507
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 264487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I didn't notice any significant changes in the actual checks here;
all of these tests already used FileCheck, so a script can batch
update them in one shot.
This commit is just to show the value of automating this process:
We have uniform formatting as opposed to a mish-mash of check
structure that changes based on individual prefs and the current
fashion. This makes it simpler to update when we find a bug or
make an enhancement.
llvm-svn: 264457
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264438
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264437
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264435
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264434
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264433
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264432
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264431
|
| |
|
|
|
|
| |
(testing script for autogeneration of check lines)
llvm-svn: 264430
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Testing out the check-generator-script that's now in the utils folder.
llvm-svn: 264424
|
| |
|
|
| |
llvm-svn: 264421
|
| |
|
|
|
|
|
|
| |
readelf -lW
Differential Revision: http://reviews.llvm.org/D18372
llvm-svn: 264415
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Patch by Evgeny Stupachenko.
Differential Revision: http://reviews.llvm.org/D18202
llvm-svn: 264407
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 264369
|
| |
|
|
|
|
|
| |
Ideally this would also happen for fneg, but that
isn't a distinct operation in the IR.
llvm-svn: 264368
|
| |
|
|
|
|
| |
We don't want to have a cost to scalarizing operations.
llvm-svn: 264364
|
| |
|
|
|
|
|
|
|
|
| |
It is incorrect to get the corresponding MBB for a ReturnInst before
SelectAllBasicBlocks since SelectAllBasicBlocks can change the
correspondence between a ReturnInst and the MBB it is in.
PR27062
llvm-svn: 264358
|
| |
|
|
|
|
|
| |
Earlier we were ignoring varargs in LowerCallSiteWithDeoptBundle because
populateCallLoweringInfo does not set CallLoweringInfo::IsVarArg.
llvm-svn: 264354
|
| |
|
|
|
|
|
|
| |
Going to be reading the DW_AT_GNU_dwo_name shortly as well, and there
was already enough duplication here that it was worth refactoring
rather than adding even more.
llvm-svn: 264350
|
| |
|
|
| |
llvm-svn: 264349
|
| |
|
|
|
|
| |
This fixes http://llvm.org/PR26991
llvm-svn: 264345
|
| |
|
|
|
|
|
|
| |
We try to hoist the insertion point as high as possible to encourage
sharing. However, we must be careful not to hoist into a catchswitch as
it is both an EHPad and a terminator.
llvm-svn: 264344
|
| |
|
|
|
|
| |
making sure we give it a register and mark it as a register constraint.
llvm-svn: 264340
|
| |
|
|
| |
llvm-svn: 264339
|