| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We mustn't introduce a shift of exactly 64-bits for any inputs, since that's an
UNDEF value (and worse, it's not what you want with the natural Arch64
implementation).
The generated code is pretty horrific, but I couldn't come up with an obviously
better alternative (if the amount is constant EXTR could help). Turns out
128-bit shifts are just nasty.
rdar://22491037
llvm-svn: 254475
|
| |
|
|
| |
llvm-svn: 254473
|
| |
|
|
| |
llvm-svn: 254469
|
| |
|
|
| |
llvm-svn: 254468
|
| |
|
|
| |
llvm-svn: 254466
|
| |
|
|
| |
llvm-svn: 254465
|
| |
|
|
|
|
|
|
| |
The bug is introduced in r254377 which failed some tests on ARM, where a new
probability is assigned to a successor but the provided BB may not be a
successor.
llvm-svn: 254463
|
| |
|
|
|
|
|
|
| |
The values in this field are compared against getAvailableFeatures()
which returns an uint64_t. This was causing problems in an internal
branch.
llvm-svn: 254462
|
| |
|
|
| |
llvm-svn: 254459
|
| |
|
|
|
|
|
|
|
|
|
| |
profile data
Profile readers using incompatible on-disk hash table format can now share the same
implementation and interfaces.
Differential Revision: http://reviews.llvm.org/D15100
llvm-svn: 254458
|
| |
|
|
| |
llvm-svn: 254457
|
| |
|
|
|
|
|
|
| |
ConstantDataArray::getImpl and ConstantDataVector::getImpl had a lot
of copy pasta in how they handled sequences of constants. Break that
out into a couple of simple functions.
llvm-svn: 254456
|
| |
|
|
|
|
|
| |
Most of the file has been changed recently and was already clang-format
clean.
llvm-svn: 254454
|
| |
|
|
| |
llvm-svn: 254453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't use commuteInstruction, and don't commute if
doing so will not improve legality. Skip the more
complex checks for literal operands and constant bus restrictions,
which are not a concern for VOP2 instructions because src1
does not accept SGPRs or constants and few implicitly
read vcc.
This gets called quite a few times and the
attempts at commuting are a significant fraction
of the time spent in SIFixSGPRCopies, so it's
somewhat worthwhile to optimize. With this patch and others
leading up to it, this reduces the compile time of SIFixSGPRCopies
on some of the LuxMark 2 kernels from ~8ms to ~5ms on my system.
llvm-svn: 254452
|
| |
|
|
|
|
|
| |
The linker never takes ownership of a module or changes which module it
is refering to, making it natural to use references.
llvm-svn: 254449
|
| |
|
|
|
|
| |
This fixes PR25629.
llvm-svn: 254448
|
| |
|
|
| |
llvm-svn: 254447
|
| |
|
|
| |
llvm-svn: 254445
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This had been broken for a very long time, but nobody noticed until
D14357 enabled shrink-wrapping by default.
Reviewers: jroelofs, qcolombet
Subscribers: tyomitch, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14986
llvm-svn: 254444
|
| |
|
|
| |
llvm-svn: 254442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When not useful bits, BitWidth becomes 0 and APInt will not be happy.
See https://llvm.org/bugs/show_bug.cgi?id=25571
We can just mark the operand as IMPLICIT_DEF is none bits of it is used.
Reviewers: t.p.northover, jmolloy
Subscribers: gberry, jmolloy, mgrang, aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14803
llvm-svn: 254440
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The cost for scalarized operations is computed as N * (scalar operation
cost + 1 extractelement + 1 insertelement). This partially fixes
inflating the cost of scalarized operations since every operation is
scalarized and free. I don't think we want any cost asociated with
scalarization, but for now insertelement is still counted. I'm not sure
if we should pretend that insertelement is also free, or add a way
to compute a custom scalarization cost.
llvm-svn: 254438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
By including the module name in the error message.
This makes the error message much more useful and
saves a trip to the debugger.
Reviewers: dexonsmith
Subscribers: dexonsmith, llvm-commits
Differential Revision: http://reviews.llvm.org/D14473
llvm-svn: 254437
|
| |
|
|
| |
llvm-svn: 254436
|
| |
|
|
| |
llvm-svn: 254435
|
| |
|
|
|
|
|
|
|
|
|
| |
It was only used from LTO for a debug feature, and LTO can just create
another linker.
It is pretty odd to have a method to reset the module in the middle of a
link. It would make IdentifiedStructTypes inconsistent with the Module
for example.
llvm-svn: 254434
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D15050
llvm-svn: 254427
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes the assembly output look nicer and there is no reason to
have custom strings for these.
Reviewers: arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D14671
llvm-svn: 254426
|
| |
|
|
| |
llvm-svn: 254425
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It has to be a bit special because:
* materializeInitFor is not really supposed to call replaceAllUsesWith.
The caller has a plain variable with Dst and expects just the
initializer to be set, not for it to be removed.
* Calling mutateType as we used to do before gets some type
inconsistency which breaks the bitcode writer.
* If linkAppendingVarProto create a dest decl with the correct type to
avoid the above problems, it needs to put the original dst init in
some side table for materializeInitFor to use.
In the end the simplest solution seems to be to just have
linkAppendingVarProto do all the work and set ValueMap[SrcGV to avoid
recursion.
llvm-svn: 254424
|
| |
|
|
|
|
| |
Missed in a couple places.
llvm-svn: 254422
|
| |
|
|
|
|
| |
Stale as of r254036 which added basic profitability check.
llvm-svn: 254421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The difference is that now we don't error on out-of-comdat access to
internal global values. We copy them instead. This seems to match the
expectation of COFF linkers (see pr25686).
Original message:
Start deciding earlier what to link.
A traditional linker is roughly split in symbol resolution and
"copying
stuff".
The two tasks are badly mixed in lib/Linker.
This starts splitting them apart.
With this patch there are no direct call to linkGlobalValueBody or
linkGlobalValueProto. Everything is linked via WapValue.
This also includes a few fixes:
* A GV goes undefined if the comdat is dropped (comdat11.ll).
* We error if an internal GV goes undefined (comdat13.ll).
* We don't link an unused comdat.
The first two match the behavior of an ELF linker. The second one is
equivalent to running globaldce on the input.
llvm-svn: 254418
|
| |
|
|
| |
llvm-svn: 254416
|
| |
|
|
|
|
| |
(vvsqrtss was generated before)
llvm-svn: 254411
|
| |
|
|
| |
llvm-svn: 254409
|
| |
|
|
|
|
|
|
|
| |
Cost calculation for vector GEP failed with due to invalid cast to GEP index operand.
The bug is fixed, added a test.
http://reviews.llvm.org/D14976
llvm-svn: 254408
|
| |
|
|
|
|
|
|
| |
SEL.fmt, SELEQZ.fmt, SELNEQZ.fmt and CLASS.fmt
Differential Revision: http://reviews.llvm.org/D13885
llvm-svn: 254405
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The @llvm.get.dynamic.area.offset.* intrinsic family is used to get the offset
from native stack pointer to the address of the most recent dynamic alloca on
the caller's stack. These intrinsics are intendend for use in combination with
@llvm.stacksave and @llvm.restore to get a pointer to the most recent dynamic
alloca. This is useful, for example, for AddressSanitizer's stack unpoisoning
routines.
Patch by Max Ostapenko.
Differential Revision: http://reviews.llvm.org/D14983
llvm-svn: 254404
|
| |
|
|
|
|
|
|
|
|
| |
Previously it is not allowed for each MBB to have successors with both known and
unknown probabilities. However, this may be too strict as at this stage we could
not always guarantee that. It is better to remove this restriction now, and I
will work on validating MBB's successors' probabilities first (for example,
check if the sum is approximate one).
llvm-svn: 254402
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The Statistical Profiling Extension is an optional extension to
ARMv8.2-A. Since it is an optional extension, I have added the
FeatureSPE subtarget feature to control it. The assembler-visible parts
of this extension are the new "psb csync" instruction, which is
equivalent to "hint #17", and a number of system registers.
Differential Revision: http://reviews.llvm.org/D15021
llvm-svn: 254401
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add ARMv8.2-A to TargetParser, so that it can be used by the clang
command-line options and the .arch directive.
Most testing of this will be done in clang, checking that the
command-line options that this enables work.
Differential Revision: http://reviews.llvm.org/D15037
llvm-svn: 254400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds subtarget features for ARMv8.2-A, which builds on (and
requires the features from) ARMv8.1-A. Most assembler-visible features
of ARMv8.2-A are system instructions, and are all required parts of the
architecture, so just depend on the HasV8_2aOps subtarget feature.
There is also one large, optional feature, which adds 16-bit floating
point versions of all existing floating-point instructions (VFP and
SIMD), this is represented by the FeatureFullFP16 subtarget feature.
Differential Revision: http://reviews.llvm.org/D15036
llvm-svn: 254399
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15064
llvm-svn: 254391
|
| |
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15063
llvm-svn: 254390
|
| |
|
|
|
|
|
|
| |
memory on the left hand side of the fsub/fdiv operations in their patterns.
Not sure how to test this. I noticed by inspection in the isel tables where the same pattern tried to produce DIV and DIVR or SUB and SUBR.
llvm-svn: 254388
|
| |
|
|
| |
llvm-svn: 254387
|
| |
|
|
|
|
| |
types to size_t to match.
llvm-svn: 254386
|
| |
|
|
|
|
| |
manually. NFC
llvm-svn: 254385
|