| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
m0 is treated as a virtual register class with a single register
rather than the physical register it really is. This was updating
the live range of the used virtual copy of m0 from the first ds_read
instruction, and leaving the unused copy unchanged. This resulted in a
"Live segment doesn't end at a valid instruction" verifier error because
the erased instructions. Update the live range of the second copy (which
should be dead).
No test since I'm not sure how to trigger this with SIFoldOperands
enabled.
llvm-svn: 223203
|
|
|
|
|
|
|
| |
Add missing `void` return type from `!LLVM_HAS_VARIADIC_TEMPLATES` case
in r223201.
llvm-svn: 223202
|
|
|
|
| |
llvm-svn: 223201
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
/export option can be given multiple times to specify multiple
symbols to be exported. /export accepts both decorated and
undecorated name.
If you give both undecorated and decorated name of the same symbol
to /export, they are resolved to the same symbol. In this case,
we need to de-duplicate the exported names, so that we don't have
duplicated items in the export symbol table in a DLL.
We remove duplicate items from a vector. The bug was there.
Because we had pointers pointing to elements of the vector,
after an item is removed, they would point wrong elements.
This patch is to remove these pointers. Added a test for that case.
llvm-svn: 223200
|
|
|
|
|
|
|
|
| |
We were assuming that each back-edge in a region represented a unique
loop, which is not always the case. We need to use LoopInfo to
correctly determine which back-edges are loops.
llvm-svn: 223199
|
|
|
|
|
|
| |
`MDNode` does not inherit from `User`, and it never has a name.
llvm-svn: 223198
|
|
|
|
|
|
|
|
| |
We just needed to remove the assertion in
AMDGPURegisterInfo::getFrameRegister(), which is called when
initializing the parser for inline assembly.
llvm-svn: 223197
|
|
|
|
|
|
| |
Patch from Ryan Goodfellow.
llvm-svn: 223196
|
|
|
|
| |
llvm-svn: 223195
|
|
|
|
|
|
| |
This matches SC's behavior.
llvm-svn: 223194
|
|
|
|
|
|
| |
between afterwards. This is what gcc always does, and some out of tree tools depend on that.
llvm-svn: 223193
|
|
|
|
| |
llvm-svn: 223192
|
|
|
|
| |
llvm-svn: 223191
|
|
|
|
|
|
|
|
|
|
|
|
| |
As the semantics of prefix data has changed. See D6454.
Patch by Ben Gamari!
Test Plan: Testsuite
Differential Revision: http://reviews.llvm.org/D6489
llvm-svn: 223190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Ben Gamari!
This redefines the `prefix` attribute introduced previously and
introduces a `prologue` attribute. There are a two primary usecases
that these attributes aim to serve,
1. Function prologue sigils
2. Function hot-patching: Enable the user to insert `nop` operations
at the beginning of the function which can later be safely replaced
with a call to some instrumentation facility
3. Runtime metadata: Allow a compiler to insert data for use by the
runtime during execution. GHC is one example of a compiler that
needs this functionality for its tables-next-to-code functionality.
Previously `prefix` served cases (1) and (2) quite well by allowing the user
to introduce arbitrary data at the entrypoint but before the function
body. Case (3), however, was poorly handled by this approach as it
required that prefix data was valid executable code.
Here we redefine the notion of prefix data to instead be data which
occurs immediately before the function entrypoint (i.e. the symbol
address). Since prefix data now occurs before the function entrypoint,
there is no need for the data to be valid code.
The previous notion of prefix data now goes under the name "prologue
data" to emphasize its duality with the function epilogue.
The intention here is to handle cases (1) and (2) with prologue data and
case (3) with prefix data.
References
----------
This idea arose out of discussions[1] with Reid Kleckner in response to a
proposal to introduce the notion of symbol offsets to enable handling of
case (3).
[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073235.html
Test Plan: testsuite
Differential Revision: http://reviews.llvm.org/D6454
llvm-svn: 223189
|
|
|
|
| |
llvm-svn: 223188
|
|
|
|
|
|
|
|
|
|
| |
The X86AsmParser intel handling was refactored in r216481, making it
try each different memory operand size to see which one matches.
Operand sizes larger than 80 ("[xyz]mmword ptr") were forgotten, which
led to an "invalid operand" error for code such as:
movdqa [rax], xmm0
llvm-svn: 223187
|
|
|
|
|
|
|
| |
r142020 added support for has_feature(cxx_alignas). This does the same for
alignof.
llvm-svn: 223186
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Consider this program:
struct A {
virtual void operator-() { printf("base\n"); }
};
struct B final : public A {
virtual void operator-() override { printf("derived\n"); }
};
int main() {
B* b = new B;
-static_cast<A&>(*b);
}
Before this patch, clang saw the virtual call to A::operator-(), figured out
that it can be devirtualized, and then just called A::operator-() directly,
without going through the vtable. Instead, it should've looked up which
operator-() the call devirtualizes to and should've called that.
For regular virtual member calls, clang gets all this right already. So
instead of giving EmitCXXOperatorMemberCallee() all the logic that
EmitCXXMemberCallExpr() already has, cut the latter function into two pieces,
call the second piece EmitCXXMemberOrOperatorMemberCallExpr(), and use it also
to generate code for calls to virtual member operators.
This way, virtual overloaded operators automatically don't get devirtualized
if they have covariant returns (like it was done for regular calls in r218602),
etc.
This also happens to fix (or at least improve) codegen for explicit constructor
calls (`A a; a.A::A()`) in MS mode with -fsanitize-address-field-padding=1.
(This adjustment for virtual operator calls seems still wrong with the MS ABI.)
llvm-svn: 223185
|
|
|
|
|
|
| |
that contained side effects.
llvm-svn: 223184
|
|
|
|
| |
llvm-svn: 223183
|
|
|
|
|
|
|
| |
We need to use the custom expansion of readcyclecounter on all 32-bit targets
(even those with 64-bit registers). This should fix the ppc64 buildbot.
llvm-svn: 223182
|
|
|
|
| |
llvm-svn: 223181
|
|
|
|
|
|
|
|
|
|
| |
A global variable without an explicit alignment specified should be assumed to
be ABI-aligned according to its type, like on other platforms. This allows us
to use better memory operations when accessing it.
rdar://18533701
llvm-svn: 223180
|
|
|
|
| |
llvm-svn: 223179
|
|
|
|
|
|
| |
This makes it easier to debug Twine as the 'Kind' fields now show their enum values in lldb and not escaped characters.
llvm-svn: 223178
|
|
|
|
| |
llvm-svn: 223177
|
|
|
|
| |
llvm-svn: 223176
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implement _umul128; it provides the high and low halves of a 128-bit
multiply. We can simply use our __int128 arithmetic to implement this,
we generate great code for it:
movq %rdx, %rax
mulq %rcx
movq %rdx, (%r8)
retq
Differential Revision: http://reviews.llvm.org/D6486
llvm-svn: 223175
|
|
|
|
|
|
|
|
|
|
|
|
| |
preserved) in the ABI.
Realistically lldb isn't able to track register saves of any of
the neon regs right now so we should probably mark all of the
regs as unavailable when you're not on stack frame 0...
<rdar://problem/19115127>
llvm-svn: 223174
|
|
|
|
|
|
|
|
| |
There's no need to use different names for the local variables than we
use in the profile itself, and it's a bit simpler and easier to debug
if we're consistent.
llvm-svn: 223173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This frequently leads to cases like:
ldr xD, [xN, :lo12:var]
add xA, xN, :lo12:var
ldr xD, [xA, #8]
where the ADD would have been needed anyway, and the two distinct addressing
modes can prevent the formation of an ldp. Because of how we handle ADRP
(aggressively forming an ADRP/ADD pseudo-inst at ISel time), this pattern also
results in duplicated ADRP instructions (one on its own to cover the ldr, and
one combined with the add).
llvm-svn: 223172
|
|
|
|
|
|
| |
rdar://problem/18886083
llvm-svn: 223171
|
|
|
|
|
|
|
|
| |
Such loops shouldn't be vectorized due to the loops form.
After applying loop-rotate (+simplifycfg) the tests again start to check
what they are intended to check.
llvm-svn: 223170
|
|
|
|
|
|
| |
rdar://19116886
llvm-svn: 223168
|
|
|
|
|
|
|
|
| |
It doesn't make much sense to have std::unique_ptrs of std::string and
std::vector. Avoid some useless indirection by using these types
directly.
llvm-svn: 223166
|
|
|
|
|
|
|
|
|
|
| |
4i32 shuffles for single insertions into zero vectors lowers to X86vzmovl which was using (v)blendps - causing domain switch stalls. This patch fixes this by using (v)pblendw instead.
The updated tests on test/CodeGen/X86/sse41.ll still contain a domain stall due to the use of insertps - I'm looking at fixing this in a future patch.
Differential Revision: http://reviews.llvm.org/D6458
llvm-svn: 223165
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No functionality change.
Test Plan: make check-all
Reviewers: kcc
Reviewed By: kcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D6472
llvm-svn: 223164
|
|
|
|
|
|
|
|
| |
--xunit-xml-output saves test results to disk in JUnit's xml format. This will allow Jenkins to report the details of a lit run.
Based on a patch by David Chisnall.
llvm-svn: 223163
|
|
|
|
|
|
|
| |
Also have CorrectDelayedTyposInExpr check that the Expr* isn't null
before trying to access its members. Fixes PR21679.
llvm-svn: 223162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've long supported readcyclecounter on PPC64, but it is easier there (the
read of the 64-bit time-base register can be accomplished via a single
instruction). This now provides an implementation for PPC32 as well. On PPC32,
the time-base register is still 64 bits, but can only be read 32 bits at a time
via two separate SPRs. The ISA manual explains how to do this properly (it
involves re-reading the upper bits and looping if the counter has wrapped while
being read).
This requires PPC to implement a custom integer splitting legalization for the
READCYCLECOUNTER node, turning it into a target-specific SDAG node, which then
gets turned into a pseudo-instruction, which is then expanded to the necessary
sequence (which has three SPR reads, the comparison and the branch).
Thanks to Paul Hargrove for pointing out to me that this was still unimplemented.
llvm-svn: 223161
|
|
|
|
| |
llvm-svn: 223160
|
|
|
|
|
|
| |
full contents of the class.
llvm-svn: 223159
|
|
|
|
| |
llvm-svn: 223157
|
|
|
|
|
|
|
|
|
|
| |
Reduce the number of nops emitted for stackmap shadows on AArch64 by counting
non-stackmap instructions up to the next branch target towards the requested
shadow.
<rdar://problem/14959522>
llvm-svn: 223156
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D6484
Reviewed by: Oleksiy Vyalov
llvm-svn: 223155
|
|
|
|
| |
llvm-svn: 223154
|
|
|
|
|
|
|
| |
had support for. We're still missing a binding for an MCJIT
memory manager.
llvm-svn: 223153
|
|
|
|
|
|
| |
This should help our buildbots and may also simplify life for other people.
llvm-svn: 223152
|
|
|
|
| |
llvm-svn: 223151
|