| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
multiclass containing a defm called NAME that references another multiclass that contains a defm that uses NAME concatenated with other strings.
It would end up doing the concatenations from the second multiclass twice. This occured because SetValue detected a self assignment when trying to set the value of NAME to a VarInit called NAME. NAME is special here and it will get cleaned up later. So add a flag to suppress the self assignment check for this case.
Strangely the self-assignment error was returning false indicating it wasn't an error, but it wasn't doing the right thing. So this also changes it to report an error.
This fixes the names of some AVX512 FMA instructions that showed this double expansion.
llvm-svn: 256725
|
| |
|
|
|
|
| |
Obtained from FreeBSD r292611
llvm-svn: 256724
|
| |
|
|
|
|
|
|
| |
(There are changes in the copies of these four files in the FreeBSD base
system, and I've changed these ones to reduce gratuitous diffs in future
imports.)
llvm-svn: 256723
|
| |
|
|
| |
llvm-svn: 256722
|
| |
|
|
| |
llvm-svn: 256721
|
| |
|
|
| |
llvm-svn: 256720
|
| |
|
|
| |
llvm-svn: 256719
|
| |
|
|
| |
llvm-svn: 256718
|
| |
|
|
| |
llvm-svn: 256717
|
| |
|
|
|
|
|
|
| |
CoverageMapping data's section and alignment is
already set during creation. No need to call it again
during lowering.
llvm-svn: 256716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one last remaining instrumentatation related structure
that needs to be migrate to use the centralized template
definition. With this change, instrumentation code
related to coverage module header will be kept in sync
with the coverage mapping reader. The remaining code
which makes implicit assumption about covmap control
structure layout in the the lowering pass will cleaned
up in a different patch. This patch is not intended to
have no functional change.
llvm-svn: 256715
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one last remaining instrumentatation related structure
that needs to be migrate to use the centralized template
definition. With this change, instrumentation code
related to coverage module header will be kept in sync
with the coverage mapping reader. The remaining code
which makes implicit assumption about covmap control
structure layout in the the lowering pass will cleaned
up in a different patch. This patch is not intended to
have no functional change.
llvm-svn: 256714
|
| |
|
|
|
|
| |
Shows the true horror of what is going on....
llvm-svn: 256713
|
| |
|
|
| |
llvm-svn: 256712
|
| |
|
|
| |
llvm-svn: 256711
|
| |
|
|
| |
llvm-svn: 256710
|
| |
|
|
|
|
| |
Pulled out the similar CONCAT_VECTORS creation code from the 2/3 operand getNode() calls (to handle all UNDEF and all BUILD_VECTOR cases). Added a similar handler to the general getNode() call as well.
llvm-svn: 256709
|
| |
|
|
|
|
| |
Many of these could be much better if we just lowered them all as shuffles - especially for the 256-bit vectors.
llvm-svn: 256708
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, sanjoy, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D15848
llvm-svn: 256707
|
| |
|
|
|
|
| |
As mentioned on D14261, an upcoming patch will improve combines of insertps instructions.
llvm-svn: 256706
|
| |
|
|
|
|
| |
This is mainly test cases for improvements to insertps matching, but pre-SSE41 shuffles could be improved as well
llvm-svn: 256705
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D15849
llvm-svn: 256704
|
| |
|
|
|
|
| |
empty before printing. The loop can be made to print the same thing if the loop is empty. NFC
llvm-svn: 256703
|
| |
|
|
| |
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
|