| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
This patch adds a cost estimate for some missing sign and zero extensions. The
costs were determined by counting the number of shift instructions generated
without context for each new extension.
Differential Revision: http://reviews.llvm.org/D14730
llvm-svn: 253482
|
|
|
|
| |
llvm-svn: 253472
|
|
|
|
|
|
| |
operands.
llvm-svn: 253468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This also takes the push/pop syntax another step forward, introducing stack
slot numbers to make it easier to see how expressions are connected. For
example, the value pushed in $push7 is popped in $pop7.
And, this begins an experiment with making get_local and set_local implicit
when an operation directly uses or defines a register. This greatly reduces
clutter. If this experiment succeeds, it may make sense to do this for
const instructions as well.
And, this introduces more special code for ARGUMENTS; hopefully this code
will soon be obviated by proper support for live-in virtual registers.
llvm-svn: 253465
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14573
llvm-svn: 253450
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14766
llvm-svn: 253447
|
|
|
|
|
|
|
|
| |
DPSQX_S.W.PH, DPSQX_SA.W.PH, DPSU.H.QBL, DPSU.H.QBR and DPSX.W.PH instructions
Differential Revision: http://reviews.llvm.org/D14058
llvm-svn: 253443
|
|
|
|
|
|
| |
for more than a boolean check. NFC.
llvm-svn: 253441
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a section is rw, it is irrelevant if the dynamic linker will write to
it or not.
It looks like llvm implemented this because gcc was doing it. It looks
like gcc implemented this in the hope that it would put all the
relocated items close together and speed up the dynamic linker.
There are two problem with this:
* It doesn't work. Both bfd and gold will map .data.rel to .data and
concatenate the input sections in the order they are seen.
* If we want a feature like that, it can be implemented directly in the
linker since it knowns where the dynamic relocations are.
llvm-svn: 253436
|
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14357
rdar://problem/21942589
llvm-svn: 253411
|
|
|
|
| |
llvm-svn: 253396
|
|
|
|
| |
llvm-svn: 253391
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now that there is a one-to-one mapping from MachineFunction to
WinEHFuncInfo, we don't need to use a DenseMap to select the right
WinEHFuncInfo for the current funclet.
The main challenge here is that X86WinEHStatePass is an IR pass that
doesn't have access to the MachineFunction. I gave it its own
WinEHFuncInfo object that it uses to calculate state numbers, which it
then throws away. As long as nobody creates or removes EH pads between
this pass and SDAG construction, we will get the same state numbers.
The other thing X86WinEHStatePass does is to mark the EH registration
node. Instead of communicating which alloca was the registration through
WinEHFuncInfo, I added the llvm.x86.seh.ehregnode intrinsic. This
intrinsic generates no code and simply marks the alloca in use.
Reviewers: JCTremoulet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14668
llvm-svn: 253378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The underlying issues surrounding codegen for 32-bit vselects have been resolved. The pessimistic costs for 64-bit vselects remain due to the bad
scalarization that is still happening there.
I tested this on A57 in T32, A32 and A64 modes. I saw no regressions, and some improvements.
From my benchmarks, I saw these improvements in A57 (T32)
spec.cpu2000.ref.177_mesa 5.95%
lnt.SingleSource/Benchmarks/Shootout/strcat 12.93%
lnt.MultiSource/Benchmarks/MiBench/telecomm-CRC32/telecomm-CRC32 11.89%
I also measured A57 A32, A53 T32 and A9 T32 and found no performance regressions. I see much bigger wins in third-party benchmarks with this change
Differential Revision: http://reviews.llvm.org/D14743
llvm-svn: 253349
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SELECT_CC has the nasty property of having operands with unrelated
types. So if you do something like:
f32 = select_cc f16, f16, f32, f32, cc
You'd only look for the action for <select_cc, f32>, but never f16.
If the types are all legal, but the op isn't (as for f16 on AArch64,
or for f128 on x86_64/AArch64?), then you get into trouble.
For f128, we have softenSetCCOperands to handle this case.
Similarly, for f16, we can directly promote the CC operands.
llvm-svn: 253344
|
|
|
|
| |
llvm-svn: 253335
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14664
llvm-svn: 253334
|
|
|
|
|
|
|
|
| |
EXTR_S.H, EXTRV[_RS].W and EXTRV_S.H instructions
Differential Revision: http://reviews.llvm.org/D14174
llvm-svn: 253332
|
|
|
|
| |
llvm-svn: 253331
|
|
|
|
|
|
|
|
| |
SUBQH[_R].W, SUBU[_S].PH, SUBU[_S].QB and SUBUH[_R].QB instructions
Differential Revision: http://reviews.llvm.org/D14114
llvm-svn: 253329
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if the assembler encounters an error after parsing (such as an
out-of-range fixup), it reports this as a fatal error, and so stops after the
first error. However, for most of these there is an obvious way to recover
after emitting the error, such as emitting the fixup with a value of zero. This
means that we can report on all of the errors in a file, not just the first
one. MCContext::reportError records the fact that an error was encountered, so
we won't actually emit an object file with the incorrect contents.
Differential Revision: http://reviews.llvm.org/D14717
llvm-svn: 253328
|
|
|
|
|
|
|
|
| |
PRECEQU.PH.QBLA, PRECEQU.PH.QBR, PRECEQU.PH.QBRA, PRECEU.PH.QBL, PRECEU.PH.QBLA, PRECEU.PH.QBR and PRECEU.PH.QBRA instructions
Differential Revision: http://reviews.llvm.org/D14279
llvm-svn: 253326
|
|
|
|
| |
llvm-svn: 253324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The way prelink used to work was
* The compiler decides if a given section only has relocations that
are know to point to the same DSO. If so, it names it
.data.rel.ro.local<something>.
* The static linker puts all of these together.
* The prelinker program assigns addresses to each library and resolves
the local relocations.
There are many problems with this:
* It is incompatible with address space randomization.
* The information passed by the compiler is redundant. The linker
knows if a given relocation is in the same DSO or not. If could sort
by that if so desired.
* There are newer ways of speeding up DSO (gnu hash for example).
* Even if we want to implement this again in the compiler, the previous
implementation is pretty broken. It talks about relocations that are
"resolved by the static linker". If they are resolved, there are none
left for the prelinker. What one needs to track is if an expression
will require only dynamic relocations that point to the same DSO.
At this point it looks like the prelinker is an historical curiosity.
For example, fedora has retired it because it failed to build for two
releases
(http://pkgs.fedoraproject.org/cgit/prelink.git/commit/?id=eb43100a8331d91c801ee3dcdb0a0bb9babfdc1f)
This patch removes support for it. That is, it stops printing the
".local" sections.
llvm-svn: 253280
|
|
|
|
|
|
|
|
|
|
| |
This was regressed in r252656 which wasn't quite NFC. Instead of using a
custom instruction as before, use a pattern to select CONST_I32 for the
global addrs.
Differential Revision: http://reviews.llvm.org/D14587
llvm-svn: 253276
|
|
|
|
|
|
| |
Now that we can recognise different vector sizes.
llvm-svn: 253268
|
|
|
|
|
|
| |
Now that we can recognise different vector sizes - will make future AVX512 additions easier.
llvm-svn: 253266
|
|
|
|
|
|
| |
Now that we can recognise different vector sizes - will make future AVX512 additions easier.
llvm-svn: 253260
|
|
|
|
|
|
| |
Now that we can recognise different vector sizes - will make future AVX512 additions easier.
llvm-svn: 253258
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Previously return type information for a function was derived from
return dag nodes. But this didn't work for dags with != return node. So
instead compute it directly from the LLVM function as is done for imports.
Differential Revision: http://reviews.llvm.org/D14593
llvm-svn: 253251
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is to match the new version in the spec
Reviewers: sunfish
Subscribers: jfb, llvm-commits, dschuff
Differential Revision: http://reviews.llvm.org/D14519
llvm-svn: 253249
|
|
|
|
|
|
|
| |
part of shrink wrapping.
Phabricator: http://reviews.llvm.org/D13955
llvm-svn: 253247
|
|
|
|
|
|
|
|
|
|
|
| |
On top of that, don't bother allocating and initializing UnwindHelp if
we don't have any funclets. Currently we always use RBP as our frame
pointer when funclets are present, so this change makes it impossible to
come here without any fixed stack objects.
Fixes PR25533.
llvm-svn: 253245
|
|
|
|
| |
llvm-svn: 253244
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dsanders
Subscribers: llvm-commits, dsanders
Differential Revision: http://reviews.llvm.org/D14708
llvm-svn: 253225
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Function ARMConstantIslands::doInitialJumpTablePlacement() iterates over all
basic blocks in a machine function. It calls `MI = MBB.getLastNonDebugInstr()`
to get the last instruction in each block and then uses MI->getOpcode() to
decide what to do. If getLastNonDebugInstr() returns MBB.end() (for example,
when the block does not contain any instructions) then calling getOpcode() on
this value is incorrect. Avoid this problem by checking the result of
getLastNonDebugInstr().
Differential Revision: http://reviews.llvm.org/D14694
llvm-svn: 253222
|
|
|
|
|
|
|
|
|
|
| |
Storing the source location of the expression that created a constant pool
entry allows us to emit better error messages if we later discover that the
expression cannot be represented by a relocation.
Differential Revision: http://reviews.llvm.org/D14646
llvm-svn: 253220
|
|
|
|
|
|
|
|
|
|
|
| |
The MCValue class can store a SMLoc to allow better error messages to be
emitted if an error is detected after parsing. The ARM and AArch64 assembly
parsers were not setting this, so error messages did not have source
information.
Differential Revision: http://reviews.llvm.org/D14645
llvm-svn: 253219
|
|
|
|
|
|
| |
These passes are not yet enabled by default.
llvm-svn: 253217
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
* ARMv6KZ is the "canonical" name, given in the ARMARM
* ARMv6Z is an "official abbreviation" for it, mentioned in the ARMARM
* ARMv6ZK is a popular misspelling, which we should support as an alias.
The patch corrects the handling of the names.
Functional changes:
* ARMv6Z no longer treated as an architecture in its own right
* ARMv6ZK renamed to ARMv6KZ, accepting ARMv6ZK as an alias
* arm1176jz-s and arm1176jzf-s recognized as ARMv6ZK, instead of ARMv6K
* default ARMv6K CPU changed to arm1176j-s
Reviewers: rengolin, logan, compnerd
Subscribers: aemerson, llvm-commits, rengolin
Differential Revision: http://reviews.llvm.org/D14568
llvm-svn: 253206
|
|
|
|
|
|
|
| |
This allows for accurate architecture targeting as well as removing
duplicate information (hardcoded feature strings) from MCTargetDesc.
llvm-svn: 253196
|
|
|
|
|
|
|
|
| |
This was left implicit and never ever checked, which means we could have a CMPZ against some non-zero value and we were carrying on with BFI conversion regardless.
Caught by Oliver Stannard using csmith; regression test added.
llvm-svn: 253195
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AArch64 assembler was silently ignoring instructions like this:
ldr foo, =bar
AArch64AsmParser::parseOperand was returning true as the parse failed, but was
not calling AArch64AsmParser::Error to report this to the user, so the
instruction was ignored without printing an error message.
Differential Revision: http://reviews.llvm.org/D14651
llvm-svn: 253193
|
|
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14322
llvm-svn: 253185
|
|
|
|
|
|
| |
This seems to be the most popular convention among the other backends.
llvm-svn: 253172
|
|
|
|
| |
llvm-svn: 253171
|
|
|
|
|
|
| |
It broke layering violation. Reproducible with BUILD_SHARED_LIBS=ON.
llvm-svn: 253163
|
|
|
|
|
|
|
|
| |
instructions.
Differential Revision: http://reviews.llvm.org/D14322
llvm-svn: 253160
|
|
|
|
| |
llvm-svn: 253150
|
|
|
|
| |
llvm-svn: 253148
|