| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Thanks to David Binderman <dcb314@hotmail.com> for bringing it to my
attention.
llvm-svn: 288688
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so we can stop using DW_OP_bit_piece with the wrong semantics.
The entire back story can be found here:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20161114/405934.html
The gist is that in LLVM we've been misinterpreting DW_OP_bit_piece's
offset field to mean the offset into the source variable rather than
the offset into the location at the top the DWARF expression stack. In
order to be able to fix this in a subsequent patch, this patch
introduces a dedicated DW_OP_LLVM_fragment operation with the
semantics that we used to apply to DW_OP_bit_piece, which is what we
actually need while inside of LLVM. This patch is complete with a
bitcode upgrade for expressions using the old format. It does not yet
fix the DWARF backend to use DW_OP_bit_piece correctly.
Implementation note: We discussed several options for implementing
this, including reserving a dedicated field in DIExpression for the
fragment size and offset, but using an custom operator at the end of
the expression works just fine and is more efficient because we then
only pay for it when we need it.
Differential Revision: https://reviews.llvm.org/D27361
rdar://problem/29335809
llvm-svn: 288683
|
| |
|
|
|
|
| |
This fix, while a bit complicated, preserves the reusability while fixing the issues reported on llvm-commits with visual studio generators.
llvm-svn: 288679
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We treat bitwise 'not' as a special operation and try not to reduce its all-ones mask.
Presumably, this is because a 'not' may be cheaper than a generic 'xor' or it may get
folded into another logic op if the target has those. However, if we can remove a logic
instruction by changing the xor's constant mask value, that should always be a win.
Note that the IR version of SimplifyDemandedBits() does not treat 'not' as a special-case
currently (although that's marked with a FIXME). So if you run this IR through -instcombine,
you should get the same end result. I'm hoping to add a different backend transform that
will expose this problem though, so I need to solve this first.
Differential Revision: https://reviews.llvm.org/D27356
llvm-svn: 288676
|
| |
|
|
|
|
|
|
|
|
|
| |
I noticed this gap in the scalar FP-logic matching with:
D26712
and:
rL287171
Differential Revision: https://reviews.llvm.org/D27385
llvm-svn: 288675
|
| |
|
|
| |
llvm-svn: 288671
|
| |
|
|
|
|
|
|
| |
parsing tests.
NFC intended.
llvm-svn: 288667
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Doing so changes the evaluation order for relocation composition.
Patch By: Daniel Sanders
Reviewers: vkalintiris, atanasyan
Differential Revision: https://reviews.llvm.org/D26401
llvm-svn: 288666
|
| |
|
|
| |
llvm-svn: 288663
|
| |
|
|
| |
llvm-svn: 288659
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This function seems target-independent so far: all the target-specific behaviour
is isolated in the CCAssignFn and the ValueHandler (which we're also extracting
into the generic CallLowering).
The intention is to use this in the ARM backend.
Differential Revision: https://reviews.llvm.org/D27045
llvm-svn: 288658
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: s_buffer_store_dword instructions sdata operand was called sdst in encoding. This caused disassembler to fail.
Reviewers: tstellarAMD, vpykhtin, artem.tamazov
Subscribers: arsenm, nhaehnle, rampitec
Differential Revision: https://reviews.llvm.org/D27100
llvm-svn: 288657
|
| |
|
|
|
|
|
|
|
| |
Include component in install rules for Sphinx targets. Based on
a similar suggestion for other doc targets in D24935.
Differential Revision: https://reviews.llvm.org/D24982
llvm-svn: 288656
|
| |
|
|
|
|
|
|
|
| |
A debug build of AsmMatcherEmitter would use a quadratic algorithm to
check whether std::stable_sort() actually sorted. Let's hope the authors
of our C++ standard library did that testing for us. Removing the check
gives a 3x speedup in the X86 case.
llvm-svn: 288655
|
| |
|
|
| |
llvm-svn: 288653
|
| |
|
|
|
|
|
|
| |
This may seem unusual, but makes most debug tblgen builds ~10% faster.
Usually we wouldn't care about speed that much in debug builds, but for
tblgen that also translates into build time.
llvm-svn: 288652
|
| |
|
|
| |
llvm-svn: 288651
|
| |
|
|
| |
llvm-svn: 288650
|
| |
|
|
| |
llvm-svn: 288649
|
| |
|
|
| |
llvm-svn: 288648
|
| |
|
|
| |
llvm-svn: 288647
|
| |
|
|
|
|
| |
comparison. MVT's operator== already takes care of this. NFCI
llvm-svn: 288646
|
| |
|
|
| |
llvm-svn: 288644
|
| |
|
|
| |
llvm-svn: 288643
|
| |
|
|
|
|
|
|
| |
This forces the code to call StringInit::get on the string early and
avoids storing duplicates in std::string and sometimes allows pointer
comparisons instead of string comparisons.
llvm-svn: 288642
|
| |
|
|
| |
llvm-svn: 288641
|
| |
|
|
|
|
|
|
|
|
| |
"has no symbols" link warning
Building compiler-rt on Darwin produces dozens of meaningless warnings about object files having no symbols during static archive creation. This is very intentional as compiler-rt uses #ifdefs to conditionally compile platform-specific code, and we even have a .cpp source file that only contains static asserts to make sure the environment is configured right. On Linux, this situation is fine and no warning is produced. This patch adds a libtool version detection and if it's new enough, we'll use the -no_warning_for_no_symbols flag that suppresses this warning. Build logs should be much cleaner now!
Differential Revision: https://reviews.llvm.org/D27119
llvm-svn: 288640
|
| |
|
|
|
|
|
|
| |
Introduce new constructor for STRCONCAT binop with a shortcut that
immediately concatenates if the two arguments are StringInits.
Makes the QualifyName code more readable and tablegen 2-3% faster.
llvm-svn: 288639
|
| |
|
|
| |
llvm-svn: 288638
|
| |
|
|
|
|
| |
removing spacing from syntax.
llvm-svn: 288637
|
| |
|
|
|
|
| |
scalar cmp and select sequence when AVX-512 is enabled. This matches the behavior of normal isel.
llvm-svn: 288636
|
| |
|
|
|
|
| |
Currently the fast isel code emits an avx1 instruction sequence even with avx512. This is different than normal isel. A follow up commit will fix this.
llvm-svn: 288635
|
| |
|
|
|
|
| |
parse when '-' is converted to a token.
llvm-svn: 288634
|
| |
|
|
|
|
| |
The old implementation of add_llvm_tool_symlink could fail in odd ways when building out of tree. This version solves that problem by not using the LLVM_* variables, and instead reaeding the target's properties.
llvm-svn: 288632
|
| |
|
|
| |
llvm-svn: 288628
|
| |
|
|
| |
llvm-svn: 288627
|
| |
|
|
|
|
| |
opportunities.
llvm-svn: 288622
|
| |
|
|
|
|
| |
I think these intrinsics were added after the Commutative was added to most of the rest of the intrinsics and it must have been forgotten.
llvm-svn: 288621
|
| |
|
|
| |
llvm-svn: 288619
|
| |
|
|
|
|
| |
This seems to be fixed as of r288052.
llvm-svn: 288618
|
| |
|
|
|
|
|
| |
It is not clear if it is worth the complexity to use \ on
windows. This should fix the bots.
llvm-svn: 288616
|
| |
|
|
|
|
| |
Patch by Mark Santaniello.
llvm-svn: 288615
|
| |
|
|
|
|
|
| |
All these records are internalized and will live until exit. This makes
them perfect candidates for a fast BumpPtrAllocator.
llvm-svn: 288613
|
| |
|
|
|
|
|
| |
This will allow to switch to a different string storage in an upcoming
commit.
llvm-svn: 288612
|
| |
|
|
| |
llvm-svn: 288611
|
| |
|
|
|
|
|
|
| |
This avoid an extra construction of a std::string (and a heap
allocation) when the caller only has a StringRef but no std::string at
hand.
llvm-svn: 288610
|
| |
|
|
|
|
|
| |
Changes all static helper functions in MachOObjectFile.cpp that expect a
non-null MachOObjectFile pointer to take a reference instead.
llvm-svn: 288608
|
| |
|
|
|
|
|
| |
Change SectionSymbols so that it doesn't hard-code ELF types, so that
it can be used for non-ELF targets.
llvm-svn: 288607
|
| |
|
|
|
|
|
| |
getNode already prevents formation of out of bounds constant
extract_vector_elts. Do the same for insert_vector_elt.
llvm-svn: 288603
|
| |
|
|
|
|
|
| |
Use the target triple to determine whether to run the explicit-locals
pass, rather than using a separate command-line argument.
llvm-svn: 288602
|