Commit Graph

123 Commits

Author SHA1 Message Date
Justin Lebar de805b12a8 Speed up Function::isIntrinsic() by adding a bit to GlobalValue. NFC
Summary:
Previously isIntrinsic() called getName().  This involves a hashtable
lookup, so is nontrivially expensive.  And isIntrinsic() is called
frequently, particularly by dyn_cast<IntrinsicInstr>.

This patch steals a bit of IntID and uses that to store whether or not
getName() starts with "llvm."

Reviewers: bogner, arsenm, joker-eph

Subscribers: sanjoy, llvm-commits

Differential Revision: https://reviews.llvm.org/D22949

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@290691 91177308-0d34-0410-b5e6-96231b3b80d8
2016-12-28 22:59:45 +00:00
Elena Demikhovsky 872445f31f Expandload and Compressstore intrinsics
2 new intrinsics covering AVX-512 compress/expand functionality.
This implementation includes syntax, DAG builder, operation lowering and tests.
Does not include: handling of illegal data types, codegen prepare pass and the cost model.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285876 91177308-0d34-0410-b5e6-96231b3b80d8
2016-11-03 03:23:55 +00:00
Peter Collingbourne 6ff6048618 IR: Deduplicate getParent() functions on derived classes of GlobalValue into the base class. NFCI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285050 91177308-0d34-0410-b5e6-96231b3b80d8
2016-10-25 02:54:08 +00:00
Dehao Chen 977fc82cac Use profile info to set function section prefix to group hot/cold functions.
Summary:
The original implementation is in r261607, which was reverted in r269726 to accomendate the ProfileSummaryInfo analysis pass. The new implementation:
1. add a new metadata for function section prefix
2. query against ProfileSummaryInfo in CGP to set the correct section prefix for each function
3. output the section prefix set by CGP

Reviewers: davidxl, eraman

Subscribers: vsk, llvm-commits

Differential Revision: https://reviews.llvm.org/D24989

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@284533 91177308-0d34-0410-b5e6-96231b3b80d8
2016-10-18 20:42:47 +00:00
Mehdi Amini d1e3c5aaec Don't create a SymbolTable in Function when the LLVMContext discards value names (NFC)
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.

This is a recommit of r281806 after fixing the accessor to return
a pointer instead of a reference and updating all the call-sites.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281813 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-17 06:00:02 +00:00
Mehdi Amini 977635df54 Revert "Don't create a SymbolTable in Function when the LLVMContext discards value names (NFC)"
This reverts commit r281806. It introduces undefined behavior as an
API is returning a reference to the Symtab

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281808 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-17 04:36:46 +00:00
Mehdi Amini e3e722b910 Don't create a SymbolTable in Function when the LLVMContext discards value names (NFC)
The ValueSymbolTable is used to detect name conflict and rename
instructions automatically. This is not needed when the value
names are automatically discarded by the LLVMContext.
No functional change intended, just saving a little bit of memory.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@281806 91177308-0d34-0410-b5e6-96231b3b80d8
2016-09-17 03:39:01 +00:00
Pete Cooper 75494aa604 Add comments and an assert to follow-up on r279113. NFC.
Philip commented on r279113 to ask for better comments as to
when to use the different versions of getName.  Its also possible
to assert in the simple case that we aren't an overloaded intrinsic
as those have to use the more capable version of getName.

Thanks for the comments Philip.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279466 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-22 20:18:28 +00:00
Pete Cooper a13b2e5313 Add a version of Intrinsic::getName which is more efficient when there are no overloads.
When running 'opt -O2 verify-uselistorder-nodbg.lto.bc', there are 33m allocations.  8.2m
come from std::string allocations in Intrinsic::getName().  Turns out this method only
returns a std::string because it needs to handle overloads, but that is not the common case.

This adds an overload of getName which just returns a StringRef when there are no overloads
and so saves on the allocations.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@279113 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-18 18:30:54 +00:00
Justin Bogner 7d7a23e700 Replace a few more "fall through" comments with LLVM_FALLTHROUGH
Follow up to r278902. I had missed "fall through", with a space.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278970 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-17 20:30:52 +00:00
Vedant Kumar 5987faf07f [IR] Remove some unused #includes (NFC)
I needed a reader-writer lock for a downstream project and noticed that
llvm has one. Function.cpp is the only file in-tree that refers to it.
To anyone reading this: are you using RWMutex in out-of-tree code? Maybe
it's not worth keeping around any more...

Since we're not actually using RWMutex *here*, remove the #include (and
a few other stale headers while we're at it).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@278178 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-09 23:14:37 +00:00
David Callahan fcb7a4a31d [AutoFDO] Fix handling of empty profiles
Summary:
If a profile has no samples for a function, then the function "entry count" is set to the value 0. Several places in the code test that if the Function::getEntryCount is defined at all. Here we change to treat a 0 entry count the same as undefined.

In particular, this fixes a problem in getLayoutSuccessorProbThreshold in MachineBlockPlacement.cpp where we use a different and inferior heuristic for laying out basic blocks.

Reviewers: danielcdh, dnovillo

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D23082

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277849 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-05 18:38:19 +00:00
Tim Northover 9c9955b41f CodeGen: add new "intrinsic" MachineOperand kind.
This will be used during GlobalISel, where we need a more robust and readable
way to write tests than a simple immediate ID.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277209 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-29 20:32:59 +00:00
Justin Lebar 24dbd38b83 Revert "Don't invoke getName() from Function::isIntrinsic().", rL276942.
This broke some out-of-tree AMDGPU tests that relied on the old behavior
wherein isIntrinsic() would return true for any function that starts
with "llvm.".  And in general that change will not play nicely with
out-of-tree backends.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@277087 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-28 23:58:15 +00:00
Justin Lebar 6d9563a0bc Don't invoke getName() from Function::isIntrinsic().
Summary:
getName() involves a hashtable lookup, so is expensive given how
frequently isIntrinsic() is called.  (In particular, many users cast to
IntrinsicInstr or one of its subclasses before calling
getIntrinsicID().)

This has an incidental functional change: Before, isIntrinsic() would
return true for any function whose name started with "llvm.", even if it
wasn't properly an intrinsic.  The new behavior seems more correct to
me, because it's strange to say that isIntrinsic() is true, but
getIntrinsicId() returns "not an intrinsic".

Some callers want the old behavior -- they want to know whether the
caller is a recognized intrinsic, or might be one in some other version
of LLVM.  For them, we added Function::hasLLVMReservedName(), which
checks whether the name starts with "llvm.".

This change is good for a 1.5% e2e speedup compiling a large Eigen
benchmark.

Reviewers: bogner

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D22065

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@276942 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-27 23:46:57 +00:00
Justin Bogner a3d02c75b3 IR: Sort generic intrinsics before target specific ones
This splits out the intrinsic table such that generic intrinsics come
first and target specific intrinsics are grouped by target. From here
we can find out which target an intrinsic is for or differentiate
between generic and target intrinsics.

The motivation here is to make it easier to move target specific
intrinsic handling out of generic code.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@275575 91177308-0d34-0410-b5e6-96231b3b80d8
2016-07-15 16:31:37 +00:00
Benjamin Kramer e96e21f003 Apply clang-tidy's modernize-loop-convert to most of lib/IR.
Only minor manual fixes. No functionality change intended.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273813 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-26 14:10:56 +00:00
Artur Pilipenko 140d9e6906 Remangle intrinsics names when types are renamed
This is a resubmittion of previously reverted rL273568.

This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html

Reviewers: mehdi_amini, reames

Differential Revision: http://reviews.llvm.org/D19373


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273686 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-24 15:10:29 +00:00
Artur Pilipenko 2630656dc9 NFC. Move verifyIntrinsicIsVarArg from verifier to Intrinsic::matchIntrinsicVarArg since it will be reused for intrinsic remangling code
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273685 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-24 14:47:27 +00:00
Hans Wennborg 99faa52b7b Revert r273568 "Remangle intrinsics names when types are renamed"
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273574 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-23 16:13:23 +00:00
Artur Pilipenko 8f9264543d Remangle intrinsics names when types are renamed
This is a fix for the problem mentioned in "LTO and intrinsics mangling" llvm-dev mail thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-April/098387.html

Reviewers: mehdi_amini, reames

Differential Revision: http://reviews.llvm.org/D19373


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273568 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-23 15:25:09 +00:00
Artur Pilipenko 5e371d9c0c NFC. Move Verifier::verifyIntrinsicType to Intrinsics.h
Move Verifier::verifyIntrinsicType to Intrinsics::matchIntrinsicsType. Will be used to accumulate overloaded types of a given intrinsic by the upcoming patch to fix intrinsics names when overloaded types are renamed.
    
Reviewed By: reames
    
Differential Revision: http://reviews.llvm.org/D19372


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@273424 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-22 14:56:33 +00:00
Amaury Sechet a2f727daf6 Add support for string attributes in the C API.
Summary: As per title. This completes the C API Attribute support.

Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight

Subscribers: mehdi_amini

Differential Revision: http://reviews.llvm.org/D21365

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272811 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-15 17:50:39 +00:00
Amaury Sechet 3564e5c13d Make sure attribute kind and attributes are named respectively Kind and Attr consistently. Historically they used to be the same the terminology is very confused in the codebase. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272704 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-14 20:27:35 +00:00
Amaury Sechet ca669104bf Make sure we have a Add/Remove/Has function for various thing that can have attribute.
Summary: This also deprecated the get attribute function familly.

Reviewers: Wallbraker, whitequark, joker.eph, echristo, rafael, jyknight

Subscribers: axw, joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D19181

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@272504 91177308-0d34-0410-b5e6-96231b3b80d8
2016-06-12 06:17:24 +00:00