| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
It seems ArrayRefs to multi-dimensional arrays confuse some compilers.
llvm-svn: 230554
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LDtocL, and other loads that roughly correspond to the TOC_ENTRY SDAG node,
represent loads from the TOC, which is invariant. As a result, these loads can
be hoisted out of loops, etc. In order to do this, we need to generate
GOT-style MMOs for TOC_ENTRY, which requires treating it as a legitimate memory
intrinsic node type. Once this is done, the MMO transfer is automatically
handled for TableGen-driven instruction selection, and for nodes generated
directly in PPCISelDAGToDAG, we need to transfer the MMOs manually.
Also, we were not transferring MMOs associated with pre-increment loads, so do
that too.
Lastly, this fixes an exposed bug where R30 was not added as a defined operand of
UpdateGBR.
This problem was highlighted by an example (used to generate the test case)
posted to llvmdev by Francois Pichet.
llvm-svn: 230553
|
| |
|
|
|
|
|
| |
It is important we add more publications with/about Polly so people
can see that work and research is actually ongoing.
llvm-svn: 230552
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for pretty-printing instruction operands. The new
output looks like:
00000000 00000010 ffffffff CIE
Version: 1
Augmentation:
Code alignment factor: 1
Data alignment factor: -4
Return address column: 8
DW_CFA_def_cfa: reg4 +4
DW_CFA_offset: reg8 -4
DW_CFA_nop:
DW_CFA_nop:
00000014 00000010 00000000 FDE cie=00000000 pc=00000000...00000022
DW_CFA_advance_loc: 3
DW_CFA_def_cfa_offset: +12
DW_CFA_nop:
llvm-svn: 230551
|
| |
|
|
|
|
|
| |
CIE pointers were never filled in before, and printing the pointer
is totally pointless anyway.
llvm-svn: 230550
|
| |
|
|
|
|
|
| |
Move the FrameEntry::dumpInstructions down in the file at some
place where it can see the declarations of FDE and CIE.
llvm-svn: 230549
|
| |
|
|
|
|
| |
To be used for dumping.
llvm-svn: 230548
|
| |
|
|
|
|
|
|
| |
This is the first commit in a small series aiming at making
debug_frame dump more useful (right now it prints a list of
opeartions without their operands).
llvm-svn: 230547
|
| |
|
|
| |
llvm-svn: 230546
|
| |
|
|
| |
llvm-svn: 230545
|
| |
|
|
|
|
|
|
| |
r230290 released the LLVM module but not the LTOModule.
rdar://19024554
llvm-svn: 230544
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Win64 epilogue structure is very restrictive, it permits a very
small number of opcodes and none of them are 'mov'.
This means that given:
mov %rbp, %rsp
pop %rbp
The mov isn't the epilogue, only the pop is. This is problematic unless
a frame pointer is present in which case we are free to do whatever we'd
like in the "body" of the function. If a frame pointer is present,
unwinding will undo the prologue operations in reverse order regardless
of the fact that we are at an instruction which is reseting the stack
pointer.
llvm-svn: 230543
|
| |
|
|
|
|
|
|
| |
diffs
between them.
llvm-svn: 230542
|
| |
|
|
| |
llvm-svn: 230541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change aligns globals to the next highest power of 2 bytes, up to a
maximum of 128. This makes it more likely that we will be able to compress
bit sets with a greater alignment. In many more cases, we can now take
advantage of a new optimization also introduced in this patch that removes
bit set checks if the bit set is all ones.
The 128 byte maximum was found to provide the best tradeoff between instruction
overhead and data overhead in a recent build of Chromium. It allows us to
remove ~2.4MB of instructions at the cost of ~250KB of data.
Differential Revision: http://reviews.llvm.org/D7873
llvm-svn: 230540
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows clang-cl to self-host cleanly with no magic setup
steps required.
After this patch, all you have to do is set CC=CXX=clang-cl and
run cmake -G Ninja.
These changes only exist to support C++ features which are
unsupported in clang-cl, so regardless of whether the user
specifies they want to use them, we still have to disable them.
llvm-svn: 230539
|
| |
|
|
| |
llvm-svn: 230538
|
| |
|
|
| |
llvm-svn: 230537
|
| |
|
|
|
|
|
|
| |
This rule works like check-cfi, but fails if the tests are unsupported.
This is useful to run on bots if we want to be sure that the tests aren't
silently being skipped.
llvm-svn: 230536
|
| |
|
|
| |
llvm-svn: 230535
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we allowed these casts only for constants declared in system
headers, which we assume are retain/release-neutral. Now also allow them
for constants in user headers, treating them as +0. Practically, this
means that we will now allow:
id x = (id)kMyGlobalConst;
But unlike with system headers we cannot mix them with +1 values:
id y = (id)(b ? kMyGlobalConst : [Obj newValAtPlusOne]); // error
id z = (id)(b ? kSystemGlobalConst: [Obj newValAtPlusOne]); // OK
Thanks to John for suggesting this improvement.
llvm-svn: 230534
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(The change was landed in r230280 and caused the regression PR22674.
This version contains a fix and a test-case for PR22674).
When emitting the increment operation, SCEVExpander marks the
operation as nuw or nsw based on the flags on the preincrement SCEV.
This is incorrect because, for instance, it is possible that {-6,+,1}
is <nuw> while {-6,+,1}+1 = {-5,+,1} is not.
This change teaches SCEV to mark the increment as nuw/nsw only if it
can explicitly prove that the increment operation won't overflow.
Apart from the attached test case, another (more realistic)
manifestation of the bug can be seen in
Transforms/IndVarSimplify/pr20680.ll.
Differential Revision: http://reviews.llvm.org/D7778
llvm-svn: 230533
|
| |
|
|
| |
llvm-svn: 230532
|
| |
|
|
|
|
|
| |
SWIG doesn't like enum : unsigned. Revert this until I can
fix this in a way that swig likes.
llvm-svn: 230531
|
| |
|
|
|
|
| |
Reviewed at http://reviews.llvm.org/D7868
llvm-svn: 230530
|
| |
|
|
|
|
|
|
| |
functions
Reviewed at http://reviews.llvm.org/D7869
llvm-svn: 230529
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
assignment'
This update contains:
- Fixes of minor issues detected by clang's scan_build
- More schedule tree infrastructure additions
This update slightly changes the output of our dependence analysis, but these
changes are purely syntactially.
llvm-svn: 230528
|
| |
|
|
|
|
|
|
|
| |
While it's true that we don't create the PDB as requested on the command
line, this is a well-documented limitation. Warning about it doesn't
help people using legacy build systems with clang-cl, and it makes the
clang-cl self-host very noisy.
llvm-svn: 230527
|
| |
|
|
|
|
|
|
| |
exported from multiple modules."
This reverts commits r230477 and r230478.
llvm-svn: 230526
|
| |
|
|
|
|
|
|
|
| |
It broke test/PCH/headersearch.cpp because it was using -Wpadding, which
only works for Itanium layout. Before this commit, we would use Itanium
record layout when using PCH, which is crazy. Now that the test uses an
explicit Itanium triple, we can reland.
llvm-svn: 230525
|
| |
|
|
|
|
|
|
|
| |
-Wpadding is not implemented in the Microsoft record layout builder.
This test only passes on Windows because PCH forces us to use the
Itanium record layout builder. I'm about to fix that, so change the
test to not rely on that ridiculous behavior.
llvm-svn: 230524
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DebuggerThread was detecting the launch error, but it was
ignored by ProcessWindows::DoLaunch, causing LLDB to wait forever
in the debugger loop.
This fixes the test case that explicitly attempts to launch a
process from a non-existant path.
Patch by Adrian McCarthy
Differential Revision: http://reviews.llvm.org/D7874
llvm-svn: 230523
|
| |
|
|
|
|
|
|
|
|
|
| |
Earlier this week I was able to get clang-cl on Windows to be
able to self host. This opened the door to being able to
get a whole new slew of warnings for the Windows build.
This patch fixes all of the warnings, many of which were real
bugs.
llvm-svn: 230522
|
| |
|
|
| |
llvm-svn: 230521
|
| |
|
|
| |
llvm-svn: 230520
|
| |
|
|
| |
llvm-svn: 230519
|
| |
|
|
|
|
|
|
| |
We had somehow accumulated a few target-specific SDAG nodes dealing with PPC64
TOC access that were referenced only in TableGen patterns. The associated
(pseudo-)instructions are used, but are being generated directly. NFC.
llvm-svn: 230518
|
| |
|
|
|
|
| |
As requested in code review.
llvm-svn: 230517
|
| |
|
|
|
|
| |
PR22699
llvm-svn: 230516
|
| |
|
|
|
|
|
|
|
|
| |
With a diabolically crafted test case, we could recurse
through this code and return true instead of false.
The larger engineering crime is the use of magic numbers.
Added FIXME comments for those.
llvm-svn: 230515
|
| |
|
|
| |
llvm-svn: 230514
|
| |
|
|
| |
llvm-svn: 230513
|
| |
|
|
|
|
|
|
|
| |
We would wrongfully reject (a.~A)() in both the destructor and
pseudo-destructor cases.
This fixes PR22668.
llvm-svn: 230512
|
| |
|
|
| |
llvm-svn: 230510
|
| |
|
|
|
|
| |
"_OBJC_CLASS_$_", "_OBJC_METACLASS_$_", and "_OBJC_IVAR_$_" non debug symbols. This allows the symbol that represents the object file to contain the eSymbolTypeObjCClass and eSymbolTypeObjCMetaClass and will help us to be able to efficiently lookup the real definition of an objective C class without loading all .o files linearly to find the .o file that contains the true definition.
llvm-svn: 230509
|
| |
|
|
|
|
| |
when using "image dump symtab".
llvm-svn: 230508
|
| |
|
|
|
|
| |
Go build for Windows
llvm-svn: 230507
|
| |
|
|
|
|
|
|
| |
'__sanitizer_annotate_contiguous_container' is not aligned error message easier to understand
This incorporates the fix for ARM architecture suggested by Renato Golin.
llvm-svn: 230506
|
| |
|
|
|
|
|
|
| |
Sorry, SVN had some weird problems so I had to revert and reapply the patch
locally a couple of times and didn't notice I've added file contents to the same
file....
llvm-svn: 230505
|
| |
|
|
| |
llvm-svn: 230504
|