| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 256702
|
| |
|
|
| |
llvm-svn: 256701
|
| |
|
|
| |
llvm-svn: 256700
|
| |
|
|
|
|
| |
comparison for readability. NFC
llvm-svn: 256699
|
| |
|
|
| |
llvm-svn: 256698
|
| |
|
|
|
|
| |
still emitted a closing curly brace.
llvm-svn: 256697
|
| |
|
|
| |
llvm-svn: 256696
|
| |
|
|
| |
llvm-svn: 256695
|
| |
|
|
| |
llvm-svn: 256694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
right before commit. Sorry about that.
Test did not catch this either, so I`ll improve it and recommit later.
Original commit message:
[ELF] - Optimize .eh_frame section: remove CIE if all FDEs referencing it were removed.
This patch performs little optimization for eh_frame section.
If all FDE`s that referenced CIE are removed then CIE is also removed from output.
That can happen for example when dropping FDEs that point to dropped sections. Testcase showing that is included.
The same optimization was added to ld about 14 years ago: https://sourceware.org/ml/binutils/2001-12/msg00144.html, gold does not do that it seems.
Differential revision: http://reviews.llvm.org/D15564
llvm-svn: 256693
|
| |
|
|
|
|
| |
Fix build break introduced by r256691.
llvm-svn: 256692
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The handler list must be nonempty and consist solely of CatchPads.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15842
llvm-svn: 256691
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: A catchswitch cannot be a parent of a cleanuppad or another catchswitch.
Reviewers: rnk, andrew.w.kaylor, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15841
llvm-svn: 256690
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add a pass to update catchrets when their successors get cloned; the
existing pass doesn't catch these because it walks the funclet whose
blocks are being cloned but the catchret is in a child funclet.
Also update the test for removing incoming PHI values; when the
predecessor is a catchret, the relevant color is the catchret's parentPad,
not its block's color.
Reviewers: andrew.w.kaylor, rnk, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15840
llvm-svn: 256689
|
| |
|
|
|
|
|
|
|
|
| |
without braces.
While the original code would work with or without braces, it makes sense to
set HaveSemi to true only if (!HaveSemi), otherwise it's already true, so I
put the assignment inside the if block. This addresses PR25998.
llvm-svn: 256688
|
| |
|
|
|
|
|
|
| |
Recolor the IR to make sure our computed colors are not hiding any bugs.
Also, verifyFunction if we are running some post-preparation operations;
some of these operations can hide latent bugs.
llvm-svn: 256687
|
| |
|
|
|
|
|
| |
Lean on LLVM to provide this functionality now that it provides the
necessary intrinsics.
llvm-svn: 256686
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM's targets need to know if stack pointer adjustments occur after the
prologue. This is needed to correctly determine if the red-zone is
appropriate to use or if a frame pointer is required.
Normally, LLVM can figure this out very precisely by reasoning about the
contents of the MachineFunction. There is an interesting corner case:
inline assembly.
The vast majority of inline assembly which will perform a push or pop is
done so to pair up with pushf or popf as appropriate. Unfortunately,
this inline assembly doesn't mark the stack pointer as clobbered
because, well, it isn't. The stack pointer is decremented and then
immediately incremented. Because of this, LLVM was changed in r256456
to conservatively assume that inline assembly contain a sequence of
stack operations. This is unfortunate because the vast majority of
inline assembly will not end up manipulating the stack pointer in any
way at all.
Instead, let's provide a more principled solution: an intrinsic.
FWIW, other compilers (MSVC and GCC among them) also provide this
functionality as an intrinsic.
llvm-svn: 256685
|
| |
|
|
|
|
|
| |
"friend class OMPVarListClause" -> "friend OMPVarListClause". It's a
template, not a class.
llvm-svn: 256684
|
| |
|
|
| |
llvm-svn: 256683
|
| |
|
|
| |
llvm-svn: 256682
|
| |
|
|
| |
llvm-svn: 256681
|
| |
|
|
|
|
| |
remove a layering violation in the Util library.
llvm-svn: 256680
|
| |
|
|
| |
llvm-svn: 256679
|
| |
|
|
| |
llvm-svn: 256678
|
| |
|
|
| |
llvm-svn: 256677
|
| |
|
|
| |
llvm-svn: 256676
|
| |
|
|
| |
llvm-svn: 256675
|
| |
|
|
|
|
|
| |
The version with OpBundles was missed in:
http://reviews.llvm.org/rL255555
llvm-svn: 256674
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15770
llvm-svn: 256673
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15837
llvm-svn: 256672
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Not folding these cases tends to avoid partial register updates:
sqrtss (%eax), %xmm0
Has a partial update of %xmm0, while
movss (%eax), %xmm0
sqrtss %xmm0, %xmm0
Has a clobber of the high lanes immediately before the partial update,
avoiding a potential stall.
Given this, we only want to fold when optimizing for size.
This is consistent with the patterns we already have for some of
the fp/int converts, and in X86InstrInfo::foldMemoryOperandImpl()
Differential Revision: http://reviews.llvm.org/D15741
llvm-svn: 256671
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15808
llvm-svn: 256670
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
r252440 to the Hexagon target.
This restores the previous behavior of not including the mnemonic in the classes table for every target that starts instruction lines with the mnemonic. Not only did the table size increase by 1 entry, but the class enum increased in size which caused every class in the array to increase in size. It also grew the size of the function that parsers tokens into classes by a substantial amount.
This adds a new HasMnemonicFirst flag to all AsmParsers. It's set to 1 by default and Hexagon target overrides it to 0.
For the X86 target alone this recovers 324KB of size on the llvm-mc executable.
I believe the current state is still a bad design choice for the Hexagon target as it causes most of the parsing to do a linear search through the entire match table to comparing operands against every instruction until it finds one that works. At least for the other targets we do a binary search based on mnemonic over which to do the linear scan.
llvm-svn: 256669
|
| |
|
|
| |
llvm-svn: 256668
|
| |
|
|
|
|
|
|
|
|
| |
This is part of the effort/prepration to reduce the size
instr-pgo (object, binary, memory footprint, and raw data).
The functionality is currently off by default and not yet
used by any clients.
llvm-svn: 256667
|
| |
|
|
|
|
|
|
| |
modifiers.
OpenMP 4.5 adds support for monotonic/nonmonotonic modifiers in 'schedule' clause. Add codegen for these modifiers.
llvm-svn: 256666
|
| |
|
|
|
|
| |
(Detected by asan)
llvm-svn: 256665
|
| |
|
|
|
|
| |
It's dead code, no functional change is intended.
llvm-svn: 256664
|
| |
|
|
|
|
| |
Just a cleanup, no functional change is intended.
llvm-svn: 256663
|
| |
|
|
|
|
|
| |
As per C++ [dcl.ref]p1, cv-qualified references are not valid. As such,
change the mangler to assert that this event does not happen.
llvm-svn: 256662
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The MS ABI emits a special default constructor closure thunk if a
default constructor has a weird calling convention or default arguments.
The MS ABI has a quirk: there can be only one such thunk because the
mangling scheme does not have room for distinct manglings. We must
raise a diagnostic in this eventuality.
N.B. MSVC sorta gets this right. Multiple default constructors result
in the default constructor closure getting emitted but they seem to
get confused by which default constructors are reasonable to reference
from the closure. We try to be a little more careful which results in
mild differences in behavior.
llvm-svn: 256661
|
| |
|
|
|
|
| |
of trying to search characters around the token. No functional change intended. Verified for in-tree targets.
llvm-svn: 256660
|
| |
|
|
| |
llvm-svn: 256659
|
| |
|
|
| |
llvm-svn: 256658
|
| |
|
|
|
|
|
|
| |
by overload resolution because deduction succeeds, but the substituted
parameter type for some parameter (with deduced type) doesn't exactly match the
corresponding adjusted argument type.
llvm-svn: 256657
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
actual""
This reverts commit r256642 and restores r256620 now that Tobias has
updated Polly.
There are still some potential problems with the code in Polly that I've
sent post-commit review about, but they're unlikely to break anything in
practice, and I'd like to avoid the rest of LLVM and Clang regressing
here.
llvm-svn: 256656
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
shift right (PR25900)
This is a fix for:
https://llvm.org/bugs/show_bug.cgi?id=25900
If we think that an arithmetic right shift of a power of two is always a power of two,
an sdiv gets wrongly converted to udiv.
Differential Revision: http://reviews.llvm.org/D15827
llvm-svn: 256655
|
| |
|
|
| |
llvm-svn: 256654
|
| |
|
|
|
|
|
|
| |
As suggested in review for r255909, rename MDMaterialized to AllowTemps,
and identify the name of the boolean flag being set in calls to
saveMetadataList.
llvm-svn: 256653
|