| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Adds support for the new Cortex-A35 ARMv8-A core.
llvm-svn: 254503
|
| |
|
|
|
|
| |
not being expanded. Test case included.
llvm-svn: 254501
|
| |
|
|
|
|
|
|
| |
REPLV.PH, REPLV.QB and MTHLIP instructions
Differential Revision: http://reviews.llvm.org/D14527
llvm-svn: 254496
|
| |
|
|
|
|
|
|
|
|
| |
On FMA targets, we can avoid having to load a constant to negate a float/double multiply by instead using a FNMSUB (-(X*Y)-0)
Fix for PR24366
Differential Revision: http://reviews.llvm.org/D14909
llvm-svn: 254495
|
| |
|
|
|
|
|
|
|
| |
I checked and updated the cost of AVX-512 conversion operations. Added cost of conversion operations in DQ mode.
Conversion of illegal types that requires vector split is not calculated right now (like for other X86 targets).
Differential Revision: http://reviews.llvm.org/D15074
llvm-svn: 254494
|
| |
|
|
|
|
|
|
| |
add builtin_ia32_vcomisd and builtin_ia32_vcomisd
Differential Revision: http://reviews.llvm.org/D14331
llvm-svn: 254493
|
| |
|
|
|
|
| |
synthesize one)
llvm-svn: 254492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
time.
The new overloaded function is used when an attribute is added to a
large number of slots of an AttributeSet (for example, to function
parameters). This is much faster than calling AttributeSet::addAttribute
once per slot, because AttributeSet::getImpl (which calls
FoldingSet::FIndNodeOrInsertPos) is called only once per function
instead of once per slot.
With this commit, clang compiles a file which used to take over 22
minutes in just 13 seconds.
rdar://problem/23581000
Differential Revision: http://reviews.llvm.org/D15085
llvm-svn: 254491
|
| |
|
|
|
|
| |
needed to only try to perform 256-it shuffle combines on legal vector types.
llvm-svn: 254490
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is very rudimentary support for debug_cu_index, but it is enough to
allow llvm-dwarfdump to find the offsets for contributions and
correctly dump debug_info.
It will need to actually find the real signature of the unit and build
the real hash table with the right number of buckets, as per the DWP
specification.
It will also need to be expanded to cover the tu_index as well.
llvm-svn: 254489
|
| |
|
|
| |
llvm-svn: 254487
|
| |
|
|
|
|
|
|
|
|
|
|
| |
single one
For efficiency reason, when importing multiple functions for the same Module,
we can avoid reparsing it every time.
Differential Revision: http://reviews.llvm.org/D15102
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254486
|
| |
|
|
| |
llvm-svn: 254484
|
| |
|
|
|
|
| |
not in addition to, regular coverage. Do the regular coverage in the run-time instead
llvm-svn: 254482
|
| |
|
|
| |
llvm-svn: 254480
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When linking static archive, there is no individual module files to
load. Instead they can be mmap'ed and could be initialized from a
buffer directly. The callback provide flexibility to override the
scheme for loading module from the summary.
Differential Revision: http://reviews.llvm.org/D15101
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 254479
|
| |
|
|
|
|
|
|
| |
This is a superset of the fix done in r254448.
This fixes PR25607.
llvm-svn: 254478
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|