| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Just as with mfocrf, it is also preferable to use mtocrf instead of
mtcrf when only a single CR register is to be written.
Current code however always emits mtcrf. This probably does not matter
when using an external assembler, since the GNU assembler will in fact
automatically replace mtcrf with mtocrf when possible. It does create
inefficient code with the integrated assembler, however.
To fix this, this patch adds MTOCRF/MTOCRF8 instruction patterns and
uses those instead of MTCRF/MTCRF8 everything. Just as done in the
MFOCRF patch committed as 185556, these patterns will be converted
back to MTCRF if MTOCRF is not available on the machine.
As a side effect, this allows to modify the MTCRF pattern to accept
the full range of mask operands for the benefit of the asm parser.
llvm-svn: 185561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When accessing just a single CR register, it is always preferable to
use mfocrf instead of mfcr, if the former is available on the CPU.
Current code makes that distinction in many, but not all places
where a single CR register value is retrieved. One missing
location is PPCRegisterInfo::lowerCRSpilling.
To fix this and make this simpler in the future, this patch changes
the bulk of the back-end to always assume mfocrf is available and
simply generate it when needed.
On machines that actually do not support mfocrf, the instruction
is replaced by mfcr at the very end, in EmitInstruction.
This has the additional benefit that we no longer need the
MFCRpseud hack, since before EmitInstruction we always have
a MFOCRF instruction pattern, which already models data flow
as required.
The patch also adds the MFOCRF8 version of the instruction,
which was missing so far.
Except for the PPCRegisterInfo::lowerCRSpilling case, no change
in generated code intended.
llvm-svn: 185556
|
|
|
|
|
|
| |
While there, use early returns to reduce nesting.
llvm-svn: 185547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The subroutine getCRIdxForSetCC has a parameter "Other" and comment:
If this returns with Other != -1, then the returned comparison
is an or of two simpler comparisons.
However for at least the last five years this routine has never
returned a value of Other != -1; these cases are now handled
differently to begin with.
This patch removes the parameter and the code in SelectSETCC that
attempted to handle the Other != -1 case.
llvm-svn: 185541
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185540
|
|
|
|
|
|
|
| |
This changes behavior of -msan-poison-stack=0 flag from not poisoning stack
allocations to actively unpoisoning them.
llvm-svn: 185538
|
|
|
|
|
|
|
|
|
|
|
| |
A couple of AltiVec patterns are just specialized forms of the
generic instruction pattern, and should therefore be marked
isCodeGenOnly to avoid confusing the asm parser:
VCFSX_0, VCTUXS_0, VCFUX_0, VCTSXS_0, and V_SETALLONES.
Noticed by inspection of the generated PPCGenAsmMatcher.inc.
llvm-svn: 185533
|
|
|
|
|
|
|
|
|
| |
This adds support for the generic forms of mtspr/mfspr
for the asm parser. The compiler will continue to use
the specialized patters for mtlr etc. since those are
needed to correctly describe data flow.
llvm-svn: 185532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a mapping from register-based <INSN>R instructions to the corresponding
memory-based <INSN>. Use it to cut down on the number of spill loads.
Some instructions extend their operands from smaller fields, so this
required a new TSFlags field to say how big the unextended operand is.
This optimisation doesn't trigger for C(G)R and CL(G)R because in practice
we always combine those instructions with a branch. Adding a test for every
other case probably seems excessive, but it did catch a missed optimisation
for DSGF (fixed in r185435).
llvm-svn: 185529
|
|
|
|
|
|
|
|
|
|
| |
issues:
1. it should accept only 4-byte aligned addresses
2. the maximum offset should be 1020
3. it should be encoded with the offset scaled by two bits
llvm-svn: 185528
|
|
|
|
|
|
|
|
|
|
|
| |
Swift cores implement store barriers that are stronger than the ARM
specification but weaker than general barriers. They are, in fact, just about
enough to provide the ordering needed for atomic operations with release
semantics.
This patch makes use of that quirk.
llvm-svn: 185527
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rename Function->DispKey and PairType->DispSize. I'd originally used
"Function" because I thought it might be useful for other InstMappings.
However, it turns out that having two very similar instructions with the
same Function makes it pretty useless for anything other than the displacement
size key. Other InstMappings will want the key to be defined for only one
instruction in the pair.
No behavioural change intended.
llvm-svn: 185526
|
|
|
|
|
|
|
| |
Get rid of some old code (and associated FIXME) for handling the
caller-allocated register save area. No behavioural change intended.
llvm-svn: 185525
|
|
|
|
| |
llvm-svn: 185523
|
|
|
|
| |
llvm-svn: 185520
|
|
|
|
| |
llvm-svn: 185519
|
|
|
|
|
|
| |
Patch by Robert Lytton.
llvm-svn: 185518
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185514
|
|
|
|
|
|
| |
specifying vector size.
llvm-svn: 185513
|
|
|
|
|
|
| |
avoid specifying the vector size unnecessarily.
llvm-svn: 185512
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185509
|
|
|
|
|
|
| |
size doesn't have to repeated when creating iterators for the DenseMap.
llvm-svn: 185508
|
|
|
|
|
|
| |
having to specify the vector size in multiple places.
llvm-svn: 185507
|
|
|
|
|
|
| |
respecifying the small vector size.
llvm-svn: 185505
|
|
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185504
|
|
|
|
|
|
|
|
|
|
| |
attributes for the posix call gettimeofday.
This implies annotating it as nounwind and its arguments as nocapture. To be
conservative, we do not annotate the arguments with noalias since some platforms
do not have restrict on the declaration for gettimeofday.
llvm-svn: 185502
|
|
|
|
|
|
|
|
|
|
|
| |
Windows.
*NOTE* In a recent version of posix, they added the restrict keyword to the
arguments for this function. From some spelunking it seems that on some
platforms, the call has restrict on its arguments and others it does not. Thus I
left off the restrict keyword from the function prototype in the comment.
llvm-svn: 185501
|
|
|
|
|
|
|
| |
avoid adding information for the debug_inlined section when it isn't
going to be emitted anyhow.
llvm-svn: 185500
|
|
|
|
| |
llvm-svn: 185499
|
|
|
|
| |
llvm-svn: 185498
|
|
|
|
| |
llvm-svn: 185497
|
|
|
|
|
|
| |
grep.
llvm-svn: 185496
|
|
|
|
| |
llvm-svn: 185495
|
|
|
|
| |
llvm-svn: 185492
|
|
|
|
|
|
| |
true, so remove the return value and propagate accordingly.
llvm-svn: 185490
|
|
|
|
|
|
|
|
| |
Correctly handles ref_addr depending on the Dwarf version. Emit Dwarf with
version from module flag.
TODO: turn on/off features depending on the Dwarf version.
llvm-svn: 185484
|
|
|
|
| |
llvm-svn: 185480
|
|
|
|
|
|
|
|
|
| |
This patch now adds support for recognizing TLS call sequences in
the asm parser. This needs a new pattern BL8_TLS, which is like
BL8_NOP_TLS except without nop. That pattern is used for the
asm parser only.
llvm-svn: 185478
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the global-dynamic and local-dynamic TLS sequences, we need
to use a special form of the call instruction:
bl __tls_get_addr(sym@tlsld)
bl __tls_get_addr(sym@tlsgd)
which generates two fixups. The current implementation of this causes
problems with recognizing this form in the asm parser. To fix this,
this patch reworks operand processing for this special form by using
a single operand to hold both __tls_get_addr and sym@tlsld and defining
a print method to output the above form, and an encoding method to
generate the two fixups.
As a side simplification, the patch replaces the two instruction
patterns BL8_NOP_TLSGD and BL8_NOP_TLSLD by a single BL8_NOP_TLS,
since the patterns already operate in an identical fashion (whether
we have a local-dynamic or global-dynamic symbol is already encoded
in the symbol modifier).
No change in code generation intended.
llvm-svn: 185477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The PowerPC-specific modifiers VK_PPC_TLSGD and VK_PPC_TLSLD
correspond exactly to the generic modifiers VK_TLSGD and VK_TLSLD.
This causes some confusion with the asm parser, since VK_PPC_TLSGD
is output as @tlsgd, which is then read back in as VK_TLSGD.
To avoid this confusion, this patch removes the PowerPC-specific
modifiers and uses the generic modifiers throughout. (The only
drawback is that the generic modifiers are printed in upper case
while the usual convention on PowerPC is to use lower-case modifiers.
But this is just a cosmetic issue.)
llvm-svn: 185476
|
|
|
|
| |
llvm-svn: 185475
|
|
|
|
|
|
|
|
|
| |
This adds an implementation of getDebugThreadLocalSymbol for
(64-bit) PowerPC. This needs to return a generic MCExpr
since on ppc64, we need to add a bias of 0x8000 to the
value returned by the R_PPC64_DTPREL64 relocation.
llvm-svn: 185461
|
|
|
|
|
|
|
|
|
|
|
| |
This allows getDebugThreadLocalSymbol to return a generic MCExpr
instead of just a MCSymbolRefExpr.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185460
|
|
|
|
|
|
|
|
|
|
|
| |
This changes the AddrPool infrastructure to enable it to hold
generic MCExpr expressions, not just MCSymbolRefExpr.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185459
|
|
|
|
|
|
|
|
|
|
|
|
| |
This partially reverts r185202 and restores DIELabel to hold plain
MCSymbol references. Instead, we add a new subclass DIEExpr of
DIEValue that can hold generic MCExpr references.
This is in preparation for supporting debug info for TLS variables
on PowerPC, where we need to describe the variable location using
a more complex expression than just MCSymbolRefExpr.
llvm-svn: 185458
|
|
|
|
| |
llvm-svn: 185456
|
|
|
|
|
|
|
|
|
|
|
| |
"Remove floating point computations form SpillPlacement.cpp."
These commits caused test failures in lencod on clang-native-arm-lnt.
I suspect these changes are only exposing an existing issue, but
reverting anyway to keep the bots passing while we investigate.
llvm-svn: 185447
|
|
|
|
| |
llvm-svn: 185445
|
|
|
|
|
|
|
| |
Originally if D.firstSigDigit == str.end(), we will have already dereferenced
D.firstSigDigit in the first predicate.
llvm-svn: 185437
|
|
|
|
|
|
|
|
| |
This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).
llvm-svn: 185436
|