| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
"the the" -> "the"
llvm-svn: 322934
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: reames, davide, anna
Reviewed By: reames, davide
Differential Revision: https://reviews.llvm.org/D42270
llvm-svn: 322933
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In ModRefInfo "Must" was introduced to track presence of MustAlias, but we still want to return NoModRef when there is neither Mod or Ref, even when MustAlias is found. Patch has small fixes to ensure this happens.
Minor cleanup to remove nesting for 2 if statements when calling getModRefInfo for 2 ImmutableCallSites.
Reviewers: sanjoy
Subscribers: jlebar, llvm-commits
Differential Revision: https://reviews.llvm.org/D42209
llvm-svn: 322932
|
|
|
|
|
|
|
|
|
|
| |
Three (or more) operand getelementptrs could plausibly also be handled, but
handling only two-operand fits in easily with the existing BinaryOperator
handling.
Differential Revision: https://reviews.llvm.org/D39958
llvm-svn: 322930
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids playing games with pseudo pass IDs and avoids using an
unreliable MRI::isSSA() check to determine whether register allocation
has happened.
Note that this renames:
- MachineLICMID -> EarlyMachineLICM
- PostRAMachineLICMID -> MachineLICMID
to be consistent with the EarlyTailDuplicate/TailDuplicate naming.
llvm-svn: 322927
|
|
|
|
|
|
|
|
| |
Split TailDuplicatePass into EarlyTailDuplicate and TailDuplicate. This
avoids playing games with fake pass IDs and using MRI::isSSA() to
determine pre-/post-RA state.
llvm-svn: 322926
|
|
|
|
|
|
|
| |
test/CodeGen/MIR is for testing the MIR parser/printer. Tests for passes
and targets belong to test/CodeGen/TARGETNAME.
llvm-svn: 322925
|
|
|
|
|
|
|
|
| |
Intel scheduler models.
Combine all the separate condition codes into a singular expression when possible.
llvm-svn: 322924
|
|
|
|
|
|
| |
One of buildbots failed. Revert for now till fix the issue.
llvm-svn: 322923
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Re-commit of r322200: The testcase shouldn't hit machineverifiers
anymore with r322917 in place.
Large callframes (calls with several hundreds or thousands or
parameters) could lead to situations in which the emergency spillslot is
out of range to be addressed relative to the stack pointer.
This commit forces the use of a frame pointer in the presence of large
callframes.
This commit does several things:
- Compute max callframe size at the end of instruction selection.
- Add mirFileLoaded target callback. Use it to compute the max callframe size
after loading a .mir file when the size wasn't specified in the file.
- Let TargetFrameLowering::hasFP() return true if there exists a
callframe > 255 bytes.
- Always place the emergency spillslot close to FP if we have a frame
pointer.
- Note that `useFPForScavengingIndex()` would previously return false
when a base pointer was available leading to the emergency spillslot
getting allocated late (that's the whole effect of this callback).
Which made no sense to me so I took this case out: Even though the
emergency spillslot is technically not referenced by FP in this case
we still want it allocated early.
Differential Revision: https://reviews.llvm.org/D40876
llvm-svn: 322919
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not create CALLSEQ_START/CALLSEQ_END when there is no callframe to
setup and the callframe size is 0.
- Fixes an invalid callframe nesting for byval arguments, which would
look like this before this patch (as in `big-byval.ll`):
...
ADJCALLSTACKDOWN 32768, 0, ... # Setup for extfunc
...
ADJCALLSTACKDOWN 0, 0, ... # setup for memcpy
...
BL &memcpy ...
ADJCALLSTACKUP 0, 0, ... # destroy for memcpy
...
BL &extfunc
ADJCALLSTACKUP 32768, 0, ... # destroy for extfunc
- Saves us two instructions in the common case of zero-sized stackframes.
- Remove an unnecessary scheduling barrier (hence the small unittest
changes).
Differential Revision: https://reviews.llvm.org/D42006
llvm-svn: 322917
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42226
llvm-svn: 322915
|
|
|
|
| |
llvm-svn: 322914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bulk queries reduce IPC/RPC overhead for cross-process JITing and expose
opportunities for parallel compilation.
The two new query methods are lookupFlags, which finds the flags for each of a
set of symbols; and lookup, which finds the address and flags for each of a
set of symbols. (See doxygen comments for more details.)
The existing JITSymbolResolver class is renamed LegacyJITSymbolResolver, and
modified to extend the new JITSymbolResolver class using the following scheme:
- lookupFlags is implemented by calling findSymbolInLogicalDylib for each of the
symbols, then returning the result of calling getFlags() on each of these
symbols. (Importantly: lookupFlags does NOT call getAddress on the returned
symbols, so lookupFlags will never trigger materialization, and lookupFlags will
never call findSymbol, so only symbols that are part of the logical dylib will
return results.)
- lookup is implemented by calling findSymbolInLogicalDylib for each symbol and
falling back to findSymbol if findSymbolInLogicalDylib returns a null result.
Assuming a symbol is found its getAddress method is called to materialize it and
the result (if getAddress succeeds) is stored in the result map, or the error
(if getAddress fails) is returned immediately from lookup. If any symbol is not
found then lookup returns immediately with an error.
This change will break any out-of-tree derivatives of JITSymbolResolver. This
can be fixed by updating those classes to derive from LegacyJITSymbolResolver
instead.
llvm-svn: 322913
|
|
|
|
|
|
|
|
| |
This adds a new instrinsic to support the rdpid instruction. The implementation is a bit weird because the intrinsic is defined as always returning 32-bits, but the assembler support thinks the instruction produces a 64-bit register in 64-bit mode. But really it zeros the upper 32 bits. So I had to add separate patterns where 64-bit mode uses an extract_subreg.
Differential Revision: https://reviews.llvm.org/D42205
llvm-svn: 322910
|
|
|
|
| |
llvm-svn: 322907
|
|
|
|
| |
llvm-svn: 322906
|
|
|
|
|
|
|
|
| |
We did this for inline call site line tables, but we hadn't done it for
regular function line tables yet. This patch copies that logic from
encodeInlineLineTable.
llvm-svn: 322905
|
|
|
|
|
|
| |
I'm cleaning up this code before I attempt to fix a line table bug.
llvm-svn: 322904
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch implements d16 support for image load, image store and image sample intrinsics.
Reviewers:
Matt, Brian.
Differential Revision:
https://reviews.llvm.org/D3991
llvm-svn: 322903
|
|
|
|
|
|
| |
Based on a patch by Henry Wong!
llvm-svn: 322902
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGen/ARM/global-merge-external.ll. NFC.
Previously, these parts weren't ever checked. The label patterns
need to be extended to match successfully on macho.
Differential Revision: https://reviews.llvm.org/D42126
llvm-svn: 322900
|
|
|
|
|
|
|
| |
This #include is necessary to provide the definitions of _fpclass
and _FPCLASS_NZ when building with libc++.
llvm-svn: 322885
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The compilation directory has always been #0, but as of DWARF v5 it is
explicitly listed in the line-table section instead of implicitly
being a reference to the compile_unit DIE's DW_AT_comp_dir attribute.
This means the dumper should number the dumped array starting with 0
or 1 depending on the DWARF version of the line table.
References in the generated DWARF are correct, it's just the dumper
that was wrong. Also some assembler-coded tests were similarly
confused about directory numbers.
llvm-svn: 322884
|
|
|
|
| |
llvm-svn: 322881
|
|
|
|
| |
llvm-svn: 322879
|
|
|
|
|
|
|
|
|
|
| |
model.
Fixes PR35958.
Differential Revision: https://reviews.llvm.org/D42175
llvm-svn: 322878
|
|
|
|
| |
llvm-svn: 322877
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixed setting predicates for compressed instructions.
Some instructions were being generated with C extension
enabled only, without proper checks for the other
required extensions like F, D and 32 and 64-bit target checks.
Affected instructions:
C_FLD, C_FLW, C_LD, C_FSD, C_FSW, C_SD,
C_JAL, C_ADDIW, C_SUBW, C_ADDW,
C_FLDSP, C_FLWSP, C_LDSP, C_FSDSP, C_FSWSP, C_SDSP
Reviewers: asb, shiva0217
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, llvm-commits
Differential Revision: https://reviews.llvm.org/D42132
llvm-svn: 322876
|
|
|
|
|
|
|
|
|
|
|
| |
On FreeBSD, it is currently not possible to build libcxxabi and link
against it, so we have been building releases with -no-libs for quite
some time.
However, libcxx and libunwind should build without problems, so provide
an option to skip just libcxxabi.
llvm-svn: 322875
|
|
|
|
| |
llvm-svn: 322874
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's some abstraction overhead in the underlying
mechanisms that were being used, and it was leading to an
abundance of small but not-free copies being made. This
showed up on a profile. Eliminating this and going back to
a low-level byte-based implementation speeds up lld with
/DEBUG between 10 and 15%.
Differential Revision: https://reviews.llvm.org/D42148
llvm-svn: 322871
|
|
|
|
|
|
|
|
| |
Committed r322867 too soon.
Differential Revision: https://reviews.llvm.org/D42239
llvm-svn: 322868
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r322086 removed the trailing information describing reg classes for each
register.
This patch adds printing reg classes next to every register when
individual operands/instructions/basic blocks are printed. In the case
of dumping MIR or printing a full function, by default don't print it.
Differential Revision: https://reviews.llvm.org/D42239
llvm-svn: 322867
|
|
|
|
| |
llvm-svn: 322865
|
|
|
|
|
|
|
|
|
|
| |
While the memmove workaround fixed it for GCC 6.3. GCC 4.8 and GCC 7.1
are still broken. I have no clue what's going on, just blacklist GCC for
now.
Needless to say this code is ubsan, asan and msan-clean.
llvm-svn: 322862
|
|
|
|
|
|
|
|
|
| |
I've seen random crashes with GCC 4.8, GCC 6.3 and GCC 7.3, triggered by
my Optional change. All of them affect a different set of targets. This
change fixes the instance of the problem I'm seeing on my local machine,
let's hope it's good enough for the other instances too.
llvm-svn: 322859
|
|
|
|
| |
llvm-svn: 322855
|
|
|
|
| |
llvm-svn: 322850
|
|
|
|
| |
llvm-svn: 322849
|
|
|
|
|
|
|
| |
* Handle more cases where the MI is not attached yet
* Add similar asserts like in MIRPrinter::print
llvm-svn: 322848
|
|
|
|
|
|
| |
Found by msan.
llvm-svn: 322847
|
|
|
|
| |
llvm-svn: 322846
|
|
|
|
| |
llvm-svn: 322844
|
|
|
|
| |
llvm-svn: 322843
|
|
|
|
| |
llvm-svn: 322839
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
types.
This makes uses of Optional more transparent to the compiler (and
clang-tidy) and generates slightly smaller code.
This is a re-land of r317019, which had issues with GCC 4.8 back then.
Those issues don't reproduce anymore, but I'll watch the buildbots
closely in case anything goes wrong.
llvm-svn: 322838
|
|
|
|
| |
llvm-svn: 322828
|
|
|
|
|
|
|
| |
Committing this separately to minimise irrelevant changes for an upcoming
patch.
llvm-svn: 322825
|
|
|
|
|
|
|
|
|
| |
Follow-up to r322120 which can cause assertions for AArch64 because
v1f64 and v1i64 are legal types.
Differential Revision: https://reviews.llvm.org/D42097
llvm-svn: 322823
|