|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| 
| 
| | PassManager and AnalysisManager template specializations as well.
llvm-svn: 262128 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | manager proxies and use those rather than repeating their definition
four times.
There are real differences between the two directions: outer AMs are
const and don't need to have invalidation tracked. But every proxy in
a particular direction is identical except for the analysis manager type
and the IR unit they proxy into. This makes them prime candidates for
nice templates.
I've started introducing explicit template instantiation declarations
and definitions as well because we really shouldn't be emitting all this
everywhere. I'm going to go back and add the same for the other
templates like this in a follow-up patch.
I've left the analysis manager as an opaque type rather than using two
IR units and requiring it to be an AnalysisManager template
specialization. I think its important that users retain the ability to
provide their own custom analysis management layer and provided it has
the appropriate API everything should Just Work.
llvm-svn: 262127 | 
| | 
| 
| 
| | llvm-svn: 262120 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This matches the behavior of the HSAIL clock instruction.
s_realmemtime is used if the subtarget supports it, and falls
back to s_memtime if not.
Also introduces new intrinsics for each of s_memtime / s_memrealtime.
llvm-svn: 262119 | 
| | 
| 
| 
| 
| 
| 
| 
| | Avoid another implicit conversion from MachineInstrBundleIterator to
MachineInstr*, this time in MachineInstrBuilder.h (this is in pursuit of
PR26753).
llvm-svn: 262118 | 
| | 
| 
| 
| 
| 
| 
| | Remove a couple of implicit conversions from MachineInstrBundleIterator
to MachineInstr*.
llvm-svn: 262116 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Take MachineInstr by reference instead of by pointer in SlotIndexes and
the SlotIndex wrappers in LiveIntervals.  The MachineInstrs here are
never null, so this cleans up the API a bit.  It also incidentally
removes a few implicit conversions from MachineInstrBundleIterator to
MachineInstr* (see PR26753).
At a couple of call sites it was convenient to convert to a range-based
for loop over MachineBasicBlock::instr_begin/instr_end, so I added
MachineBasicBlock::instrs.
llvm-svn: 262115 | 
| | 
| 
| 
| 
| 
| 
| 
| | This was split off from http://reviews.llvm.org/D17184.
Reviewed by: Sanjoy
llvm-svn: 262080 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This should save a pointer of padding from all MSVC Value subclasses.
Recall that MSVC will not pack the following bitfields together:
  unsigned Bits : 29;
  unsigned Flag1 : 1;
  unsigned Flag2 : 1;
  unsigned Flag3 : 1;
Add a static_assert because LLVM developers always trip over this
behavior. This regressed in June.
llvm-svn: 262045 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | This patch updates cmake build scripts to build on Haiku. It adds Haiku x86_64 to config.guess.
Please consider reviewing.
Pathc by Jérôme Duval.
llvm-svn: 262038 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | analyses in the new pass manager.
These just handle really basic stuff: turning a type name into a string
statically that is nice to print in logs, and getting a static unique ID
for each analysis.
Sadly, the format of passes in anonymous namespaces makes using their
names in tests really annoying so I've customized the names of the no-op
passes to keep tests sane to read.
This is the first of a few simplifying refactorings for the new pass
manager that should reduce boilerplate and confusion.
llvm-svn: 262004 | 
| | 
| 
| 
| 
| 
| | This has been fixed for some time, but the code hadn't been updated.
llvm-svn: 261996 | 
| | 
| 
| 
| | llvm-svn: 261992 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | simulating.
Summary: Check that we're using SCEV for the same loop we're simulating. Otherwise, we might try to use the iteration number of the current loop in SCEV expressions for inner/outer loops IVs, which is clearly incorrect.
Reviewers: chandlerc, hfinkel
Subscribers: sanjoy, llvm-commits, mzolotukhin
Differential Revision: http://reviews.llvm.org/D17632
llvm-svn: 261958 | 
| | 
| 
| 
| | llvm-svn: 261946 | 
| | 
| 
| 
| | llvm-svn: 261934 | 
| | 
| 
| 
| 
| 
| | It doesn't make much sense to export these symbols.
llvm-svn: 261931 | 
| | 
| 
| 
| 
| 
| | Introduce move constructor and move assignment operator to PostDominatorTree.
llvm-svn: 261910 | 
| | 
| 
| 
| 
| 
| 
| 
| | PassManager. NFC
Differential Revision: http://reviews.llvm.org/D17571
llvm-svn: 261904 | 
| | 
| 
| 
| 
| 
| 
| 
| | DominanceFrontier. NFC
Differential Revision: http://reviews.llvm.org/D17570
llvm-svn: 261903 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D17537
llvm-svn: 261902 | 
| | 
| 
| 
| 
| 
| 
| 
| | manager. NFC"
This reverts commit a3e5cc6a51ab5ad88d1760c63284294a4e34c018.
llvm-svn: 261891 | 
| | 
| 
| 
| 
| 
| 
| 
| | compute DominanceFrontier. NFC"
This reverts commit 109c38b2226a87b0be73fa7a0a8c1a81df20aeb2.
llvm-svn: 261890 | 
| | 
| 
| 
| 
| 
| 
| 
| | PassManager. NFC"
This reverts commit 8228b4d374edeb4cc0c5fddf6e1ab876918ee126.
llvm-svn: 261889 | 
| | 
| 
| 
| 
| 
| 
| 
| | PassManager. NFC
Differential Revision: http://reviews.llvm.org/D17571
llvm-svn: 261884 | 
| | 
| 
| 
| 
| 
| 
| 
| | DominanceFrontier. NFC
Differential Revision: http://reviews.llvm.org/D17570
llvm-svn: 261883 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D17537
llvm-svn: 261882 | 
| | 
| 
| 
| | llvm-svn: 261877 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | the testing more more explicit.
This will currently fail on platforms without support for getTypeName.
While an assert failure seems too harsh, I'm hoping we're OK with the
regression test failure, and I'd like to find out about what platforms
actually exist in this state if there are any so we can get
implementations in place for them.
But if we just can't fix all the host compilers to have a reasonably
portable variant of getTypeName and are worried about xfailing this test
on those platforms, I can add the horrible regular expression magic to
make the tests support "unknown" here as well.
llvm-svn: 261853 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This creates the new-style LoopPassManager and wires it up with dummy
and print passes.
This version doesn't support modifying the loop nest at all. It will
be far easier to discuss and evaluate the approaches to that with this
in place so that the boilerplate is out of the way.
llvm-svn: 261831 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | (which they emulate). This way we don't use that path when compiled with
ICC on Windows where it mimics MSVC's behavior and supports __FUNCSIG__.
Thanks for David Majnemer again for spotting this better pattern!
llvm-svn: 261827 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This extracts the type name from __PRETTY_FUNCTION__ for compilers that
support it (I've opted Clang, GCC, and ICC into this as I've tested that
they work) and from __FUNCSIG__ which is very similar on MSVC. The
routine falls back gracefully on a stub "UNKNOWN_TYPE" string with
compilers or formats it doesn't understand.
This should be enough for a lot of common cases in LLVM where the real
goal is just to log or print a type name as a debugging aid, and save
a ton of boilerplate in the process. Notably, I'm planning to use this
to remove all the getName() boiler plate from the new pass manager.
The design and implementation is based on a bunch of advice and
discussion with Richard Smith and experimenting with most versions of
Clang and GCC. David Majnemer also provided excellent advice on how best
to do this with MSVC. Richard also checked that ICC does something
reasonable and I'll watch the build bots for other compilers. It'd be
great if someone could contribute logic for xlC and/or other toolchains.
Differential Revision: http://reviews.llvm.org/D17565
llvm-svn: 261819 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | (This is the second attemp to commit this patch, after fixing pr26652 & pr26653).
This patch detects vector reductions before instruction selection. Vector
reductions are vectorized reduction operations, and for such operations we have
freedom to reorganize the elements of the result as long as the reduction of them
stay unchanged. This will enable some reduction pattern recognition during
instruction combine such as SAD/dot-product on X86. A flag is added to
SDNodeFlags to mark those vector reduction nodes to be checked during instruction
combine.
To detect those vector reductions, we search def-use chains starting from the
given instruction, and check if all uses fall into two categories:
1. Reduction with another vector.
2. Reduction on all elements.
in which 2 is detected by recognizing the pattern that the loop vectorizer
generates to reduce all elements in the vector outside of the loop, which
includes several ShuffleVector and one ExtractElement instructions.
Differential revision: http://reviews.llvm.org/D15250
llvm-svn: 261804 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: This is extracted from D17555
Reviewers: davidxl, reames, sanjoy, MatzeB, pete
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17579
llvm-svn: 261796 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This fixes bugs in copy elimination code in llvm. It slightly changes the
semantics of clearRegisterKills(). This is appropriate because:
- Users in lib/CodeGen/MachineCopyPropagation.cpp and
  lib/Target/AArch64RedundantCopyElimination.cpp and
  lib/Target/SystemZ/SystemZElimCompare.cpp are incorrect without it
  (see included testcase).
- All other users in llvm are unaffected (they pass TRI==nullptr)
- (Kill flags are optional anyway so removing too many shouldn't hurt.)
Differential Revision: http://reviews.llvm.org/D17554
llvm-svn: 261763 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This is a part of the refactoring to unify isSafeToLoadUnconditionally and isDereferenceablePointer functions. In subsequent change I'm going to eliminate isDerferenceableAndAlignedPointer from Loads API, leaving isSafeToLoadSpecualtively the only function to check is load instruction can be speculated.   
Reviewed By: hfinkel
Differential Revision: http://reviews.llvm.org/D16180
llvm-svn: 261736 | 
| | 
| 
| 
| 
| 
| 
| 
| | Reviewed By: reames, hfinkel
Differential Revision: http://reviews.llvm.org/D16144
llvm-svn: 261735 | 
| | 
| 
| 
| 
| 
| | Differential Revision: http://reviews.llvm.org/D17538
llvm-svn: 261725 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: If a function is hot, put it in text.hot section.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17532
llvm-svn: 261607 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Change TargetInstrInfo API to take `MachineInstr&` instead of
`MachineInstr*` in the functions related to predicated instructions
(I'll try to come back later and get some of the rest).  All of these
functions require non-null parameters already, so references are more
clear.  As a bonus, this happens to factor away a host of implicit
iterator => pointer conversions.
No functionality change intended.
llvm-svn: 261605 | 
| | 
| 
| 
| 
| 
| 
| 
| | This reverts commit r261582, since this bot has been broken for four
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/19399/
llvm-svn: 261604 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | These are really handles that ensure the analyses get cleared at
appropriate places, and as such copying doesn't really make sense.
Instead, they should look more like unique ownership objects. Make that
the case.
Relatedly, if you create a temporary of one and move out of it
its destructor shouldn't actually clear anything. I don't think there is
any code that can trigger this currently, but it seems like a more
robust implementation.
If folks want, I can add a unittest that forces this to be exercised,
but that seems somewhat pointless -- whether a temporary is ever created
in the innards of AnalysisManager is not really something we should be
adding a reliance on, but I didn't want to leave a timebomb in the code
here.
If anyone has a cleaner way to represent this, I'm all ears, but
I wanted to assure myself that this wasn't in fact responsible for
another bug I'm chasing down (it wasn't) and figured I'd commit that.
llvm-svn: 261594 | 
| | 
| 
| 
| 
| 
| 
| | We supported creating mergeable constant pool entries for smaller
constants but not for 32-byte AVX constants.
llvm-svn: 261584 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary: If a function is hot, put it in text.hot section.
Reviewers: davidxl
Subscribers: eraman, mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D17460
llvm-svn: 261582 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | Summary:
Since this is an IR pass it's nice to be able to write tests without
llc.  This is the counterpart of the llc test under
CodeGen/PowerPC/loop-data-prefetch.ll.
Reviewers: hfinkel
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17464
llvm-svn: 261578 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This is a little embarrassing.
When I reverted r261504 (getIterator() => getInstrIterator()) in
r261567, I did a `git grep` to see if there were new calls to
`getInstrIterator()` that I needed to migrate.  There were 10-20 hits,
and I blindly did a `sed ...` before calling `ninja check`.
However, these were `MachineInstrBundleIterator::getInstrIterator()`,
which predated r261567.  Perhaps coincidentally, these had an identical
name and return type.
This commit undoes my careless sed and restores
`MachineBasicBlock::iterator::getInstrIterator()`.
llvm-svn: 261577 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| | This reverts commit r261504, since it's not obvious the new name is
better:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160222/334298.html
I'll recommit if we get consensus that it's the right direction.
llvm-svn: 261567 | 
| | 
| 
| 
| 
| 
| 
| 
| | Rename makeNoWrapRegion to a more obvious makeGuaranteedNoWrapRegion,
and add a comment about the counter-intuitive aspects of the function.
This is to help prevent cases like PR26628.
llvm-svn: 261532 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | This reverts commit r261510, effectively reapplying r261509.  The
original commit missed a caller in AArch64ConditionalCompares.
Original commit message:
Pass non-null arguments by reference in MachineTraceMetrics::Trace,
simplifying future work to remove implicit iterator => pointer
conversions.
llvm-svn: 261511 | 
| | 
| 
| 
| 
| 
| 
| | This reverts commit r261509.  I'm not sure how this compiled locally,
but something was out of whack.
llvm-svn: 261510 |