| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch changes the computation of the hash key for DISubprogram to
be computed on a small subset of the fields. The hash is computed a
lot faster, but there might be more collision in the table.
However by carefully selecting the fields, colisions should be rare.
Using `opt` to load the IR for FastISelEmitter.cpp.o, with this patch:
- DISubprogram::getImpl() goes from 28ms to 15ms.
- DICompositeType::getImpl() goes from 6ms to 2ms
- DIDerivedType::getImpl() goes from 18 to 12ms
Reviewers: dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D16571
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263866
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ThinLTO is relying on linkInModule to import selected function.
However a lot of "magic" was hidden in linkInModule and the IRMover,
who would rename and promote global variables on the fly.
This is moving to an approach where the steps are decoupled and the
client is reponsible to specify the list of globals to import.
As a consequence some test are changed because they were relying on
the previous behavior which was importing the definition of *every*
single global without control on the client side.
Now the burden is on the client to decide if a global has to be imported
or not.
Reviewers: tejohnson
Subscribers: joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D18122
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263863
|
| |
|
|
|
|
|
|
| |
On Rafael's suggestion!
(also fix a discrepancy between this error message format and the others)
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 263860
|
| |
|
|
|
|
|
|
|
| |
We need to be careful on which registers can be explicitly handled
via copies. Prologue, Epilogue use physical registers and if one belongs
to the set of CSRsViaCopy, it will no longer be CSRed, since PEI overwrites
it after the explicit copies.
llvm-svn: 263857
|
| |
|
|
|
|
|
| |
Since CXX_FAST_TLS has a bigger set of CSRs, we don't tail call when caller
and callee have mismatched calling conventions.
llvm-svn: 263856
|
| |
|
|
|
|
|
| |
Since at O0, explicit copies via SplitCSR may not be removed even if
they are unnecessary, we choose not to use SplitCSR at O0.
llvm-svn: 263855
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid modifying other modules in `AArch64PromoteConstant` when the
constant is `ConstantData` (a horrible accident, I'm sure, caught by an
experimental follow-up to r261464).
Previously, this walked through all the users of a constant, but that
reaches into other modules when the constant doesn't depend transitively
on a `GlobalValue`! Since we're walking instructions anyway, just
modify the instructions we actually see.
As a drive-by, instead of storing `Use` and getting the instructions
again via `Use::getUser()` (which is not a constantant time lookup),
store `std::pair<Instruction, unsigned>`. Besides being cheaper, this
makes it easier to drop use-lists form `ConstantData` in the future.
(I threw this in because I was touching all the code anyway.)
Because the patch completely changes the traversal logic, it looks
like a rewrite of the pass, but the core logic is all the same (or
should be, minus the out-of-module changes). In other words, there
should be NFC as long as the LLVMContext only has a single Module.
I didn't think of a good way to test this, but I hope to submit a patch
eventually that makes walking these use-lists illegal/impossible.
llvm-svn: 263853
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18288
llvm-svn: 263852
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While not strictly necessary, since we don't support large integer
types, this avoids bugs due to silent truncation from uint64_t to a
32-bit unsigned (e.g. DL.isLegalInteger(DL.getTypeSizeInBits(Ty) )
This fixes PR26972.
Differential Revision: http://reviews.llvm.org/D18258
llvm-svn: 263850
|
| |
|
|
| |
llvm-svn: 263849
|
| |
|
|
| |
llvm-svn: 263848
|
| |
|
|
|
|
| |
This reverts commit r263825, re-instating r263797.
llvm-svn: 263847
|
| |
|
|
| |
llvm-svn: 263846
|
| |
|
|
|
|
|
| |
constructor. This should fix the recent crashes on certain
architectures.
llvm-svn: 263845
|
| |
|
|
| |
llvm-svn: 263843
|
| |
|
|
|
|
| |
Signed-off-by: Yonghong Song <yhs@plumgrid.com>
Signed-off-by: Alexei Starovoitov <ast@fb.com>
llvm-svn: 263842
|
| |
|
|
| |
llvm-svn: 263841
|
| |
|
|
|
|
|
| |
* Renamed to be camel case, consistent with other docs.
* Fixed non-ascii characters (this is what I get for writing docs on an iPad).
llvm-svn: 263840
|
| |
|
|
| |
llvm-svn: 263839
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17894
llvm-svn: 263835
|
| |
|
|
|
|
|
|
| |
This document covers how to use some of the new complex build configurations CMake supports.
Feedback and improvements welcomed!
llvm-svn: 263834
|
| |
|
|
|
|
| |
by closing stderr/stdout
llvm-svn: 263831
|
| |
|
|
| |
llvm-svn: 263829
|
| |
|
|
| |
llvm-svn: 263828
|
| |
|
|
|
|
|
|
|
|
|
| |
The loop on IVOperand's incoming values assumes IVOperand to be an
induction variable on the loop over which `S Pred X` is invariant;
otherwise loop invariant incoming values to IVOperand are not guaranteed
to dominate the comparision.
This fixes PR26973.
llvm-svn: 263827
|
| |
|
|
|
|
|
|
| |
This fails on arm.
This reverts commit 52c8e0f7119d1ea1050c0708565a8c92b73386d2.
llvm-svn: 263825
|
| |
|
|
|
|
| |
This fixes an issue with rL263658 pointed out by Tom Stellard.
llvm-svn: 263823
|
| |
|
|
|
|
|
| |
In the <DisplayString> of PointerIntPair , I cast the pointer to the actual type, so VS can leverage it while visualizing, not unlike the recent change to PointerUnion visualization.
In the expansion, the current code is casting to the incorrect type (wrong number of stars), so I fixed that as well.
llvm-svn: 263821
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds unscaled loads and sign-extend loads to the TII
getMemOpBaseRegImmOfs API, which is used to control clustering in the MI
scheduler. This is done to create more opportunities for load pairing. I've
also added the scaled LDRSWui instruction, which was missing from the scaled
instructions. Finally, I've added support in shouldClusterLoads for clustering
adjacent sext and zext loads that too can be paired by the load/store optimizer.
Differential Revision: http://reviews.llvm.org/D18048
llvm-svn: 263819
|
| |
|
|
|
|
|
| |
We aren't referencing any other kind of function currently.
Should save a bit on our debug info size.
llvm-svn: 263817
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14781
llvm-svn: 263802
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These dependencies would be used in the future to reduce the number
of instrumented blocks(http://reviews.llvm.org/rL262103)
This is submitted as a separate CL because of previous problems with
ARM.
Subscribers: aemerson
Differential Revision: http://reviews.llvm.org/D18227
llvm-svn: 263797
|
| |
|
|
|
|
| |
be disassembled.
llvm-svn: 263793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allow the selection of BUFFER_LOAD_FORMAT_x and _XY. Do this now before
the frontend patches land in Mesa. Eventually, we may want to automatically
reduce the size of loads at the LLVM IR level, which requires such overloads,
and in some cases Mesa can generate them directly.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18255
llvm-svn: 263792
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These intrinsics expose the BUFFER_ATOMIC_* instructions and will be used
by Mesa to implement atomics with buffer semantics. The intrinsic interface
matches that of buffer.load.format and buffer.store.format, except that the
GLC bit is not exposed (it is automatically deduced based on whether the
return value is used).
The change of hasSideEffects is required for TableGen to accept the pattern
that matches the intrinsic.
Reviewers: tstellarAMD, arsenm
Subscribers: arsenm, rivanvx, llvm-commits
Differential Revision: http://reviews.llvm.org/D18151
llvm-svn: 263791
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We cannot easily deduce that an offset is in an SGPR, but the Mesa frontend
cannot easily make use of an explicit soffset parameter either. Furthermore,
it is likely that in the future, LLVM will be in a better position than the
frontend to choose an SGPR offset if possible.
Since there aren't any frontend uses of these intrinsics in upstream
repositories yet, I would like to take this opportunity to change the
intrinsic signatures to a single offset parameter, which is then selected
to immediate offsets or voffsets using a ComplexPattern.
Reviewers: arsenm, tstellarAMD, mareko
Subscribers: arsenm, llvm-commits
Differential Revision: http://reviews.llvm.org/D18218
llvm-svn: 263790
|
| |
|
|
|
| |
Review: http://reviews.llvm.org/D18267
llvm-svn: 263789
|
| |
|
|
|
|
| |
Otherwise GCC fails to build it because it doesn't know the attribute.
llvm-svn: 263787
|
| |
|
|
|
|
|
|
| |
Patch by Dongyuan Liu.
Differential Revision: http://reviews.llvm.org/D17977
llvm-svn: 263786
|
| |
|
|
|
|
| |
X86 target supporting. NFC.
llvm-svn: 263781
|
| |
|
|
|
|
|
|
|
|
|
| |
Now that the resolved path cache stores the StringRef's, its
best to just always cache the results, even when realpath isn't
used. This way we'll still avoid the StringMap hashing and lookup.
This also conveniently reorganises this code in a way I need for
a future patch.
llvm-svn: 263777
|
| |
|
|
| |
llvm-svn: 263775
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFC.
ResolvedPaths was storing std::string's as a cache. We would then take those strings and look them up in the internString pool to get a unique StringRef for each path.
This patch changes ResolvedPaths to store the StringRef pointing in to the internString pool itself. This way, when getResolvedPath returns a string, we know we have the StringRef we would find in the pool anyway. We can avoid the duplicate memory of the std::string's, and also the time from the lookup.
Unfortunately my profiles show no runtime change here, but it should still save memory allocations which is nice.
Reviewed by Frederic Riss.
Differential Revision: http://reviews.llvm.org/D18259
llvm-svn: 263774
|
| |
|
|
| |
llvm-svn: 263773
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It can hurt performance to prefetch ahead too much. Be conservative for
now and don't prefetch ahead more than 3 iterations on Cyclone.
Reviewers: hfinkel
Subscribers: llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D17949
llvm-svn: 263772
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
And use this TTI for Cyclone. As it was explained in the original RFC
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758), the HW
prefetcher work up to 2KB strides.
I am also adding tests for this and the previous change (D17943):
* Cyclone prefetching accesses with a large stride
* Cyclone not prefetching accesses with a small stride
* Generic Aarch64 subtarget not prefetching either
Reviewers: hfinkel
Subscribers: aemerson, rengolin, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D17945
llvm-svn: 263771
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This wires up the pass for Cyclone but keeps it off for now because we
need a few more TTIs.
The getPrefetchMinStride value is not very well tuned right now but it
works well with CFP2006/433.milc which motivated this.
Tests will be added as part of the upcoming large-stride prefetching
patch.
Reviewers: t.p.northover
Subscribers: llvm-commits, aemerson, hfinkel, rengolin
Differential Revision: http://reviews.llvm.org/D17943
llvm-svn: 263770
|
| |
|
|
| |
llvm-svn: 263769
|
| |
|
|
|
|
| |
Suggested by Dave Blaikie in review for r263749. Thanks Dave!
llvm-svn: 263768
|
| |
|
|
|
|
|
|
| |
table.
Differential Revision: http://reviews.llvm.org/D18256
llvm-svn: 263767
|