#
bdfc9846 |
| 06-Apr-2016 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
IRMover: Steal arguments when moving functions, NFC
Instead of copying arguments from the source function to the destination, steal them. This has a few advantages.
- The ValueMap doesn't need t
IRMover: Steal arguments when moving functions, NFC
Instead of copying arguments from the source function to the destination, steal them. This has a few advantages.
- The ValueMap doesn't need to be seeded with (or cleared of) Arguments.
- Often the destination function won't have created any arguments yet, so this avoids malloc traffic.
- Argument names don't need to be copied.
Because argument lists are lazy, this required a new Function::stealArgumentListFrom helper.
llvm-svn: 265519
show more ...
|
#
9bfd0d03 |
| 01-Apr-2016 |
Manman Ren <manman.ren@gmail.com> |
Swift Calling Convention: add swifterror attribute.
A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst.
This commit does not include any target-specific change. The
Swift Calling Convention: add swifterror attribute.
A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst.
This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
llvm-svn: 265189
show more ...
|
#
f46262e0 |
| 29-Mar-2016 |
Manman Ren <manman.ren@gmail.com> |
Swift Calling Convention: add swiftself attribute.
Differential Revision: http://reviews.llvm.org/D17866
llvm-svn: 264754
|
#
b43027d1 |
| 15-Mar-2016 |
Teresa Johnson <tejohnson@google.com> |
Move global ID computation from Function to GlobalValue (NFC)
Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving t
Move global ID computation from Function to GlobalValue (NFC)
Since the static getGlobalIdentifier and getGUID methods are now called for global values other than functions, reflect that by moving these methods to the GlobalValue class.
llvm-svn: 263524
show more ...
|
#
7b05a4c2 |
| 14-Mar-2016 |
Amaury Sechet <deadalnix@gmail.com> |
Add facility to add/remove/check attribute on function and arguments.
Summary: This comes from work to make attribute manipulable via the C API.
Reviewers: gottesmm, hfinkel, baldrick, echristo, te
Add facility to add/remove/check attribute on function and arguments.
Summary: This comes from work to make attribute manipulable via the C API.
Reviewers: gottesmm, hfinkel, baldrick, echristo, tejohnson
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18128
llvm-svn: 263404
show more ...
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3 |
|
#
7a083814 |
| 18-Feb-2016 |
Richard Trieu <rtrieu@google.com> |
Remove uses of builtin comma operator.
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261270
|
#
833571ec |
| 09-Feb-2016 |
Teresa Johnson <tejohnson@google.com> |
Refactor PGO function naming and MD5 hashing support out of ProfileData
Summary: Move the function renaming logic into the Function class, and the MD5Hash routine into the MD5 header.
This will ena
Refactor PGO function naming and MD5 hashing support out of ProfileData
Summary: Move the function renaming logic into the Function class, and the MD5Hash routine into the MD5 header.
This will enable these routines to be shared with ThinLTO, which will be changed to store the MD5 hash instead of full function name in the combined index for significant size reductions. And using the same function naming for locals in the function index facilitates future integration with indirect call value profiles.
Reviewers: davidxl
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17006
llvm-svn: 260197
show more ...
|
Revision tags: llvmorg-3.8.0-rc2 |
|
#
c2752daa |
| 26-Jan-2016 |
Reid Kleckner <rnk@google.com> |
Handle more edge cases in intrinsic name binary search
I tried to make the AMDGPU intrinsic info table use this instead of another StringMatcher, and some issues arose.
llvm-svn: 258871
|
#
0b5220d0 |
| 26-Jan-2016 |
Reid Kleckner <rnk@google.com> |
Use binary search for intrinsic ID lookups
This improves compile time of Function.cpp from 57s to 37s for me locally. Intrinsic IDs are cached on the Function object, so this shouldn't regress perf
Use binary search for intrinsic ID lookups
This improves compile time of Function.cpp from 57s to 37s for me locally. Intrinsic IDs are cached on the Function object, so this shouldn't regress performance.
llvm-svn: 258774
show more ...
|
Revision tags: llvmorg-3.8.0-rc1 |
|
#
ab105bbf |
| 15-Jan-2016 |
David Blaikie <dblaikie@gmail.com> |
[opaque pointer types] Remove an unnecessary extra explicit value type in Function
Now that this is up in GlobalValue, just use the value there.
llvm-svn: 257949
|
#
599ebf27 |
| 08-Jan-2016 |
Mehdi Amini <mehdi.amini@apple.com> |
Remove static global GCNames from Function.cpp and move it to the Context
This remove the need for locking when deleting a function.
Differential Revision: http://reviews.llvm.org/D15988
From: Meh
Remove static global GCNames from Function.cpp and move it to the Context
This remove the need for locking when deleting a function.
Differential Revision: http://reviews.llvm.org/D15988
From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 257139
show more ...
|
#
9bc46b11 |
| 23-Dec-2015 |
Keno Fischer <kfischer@college.harvard.edu> |
[Function] Properly remove use when clearing personality
Summary: We need to actually remove the use of the personality function, otherwise we can run into trouble if we want to e.g. delete the pers
[Function] Properly remove use when clearing personality
Summary: We need to actually remove the use of the personality function, otherwise we can run into trouble if we want to e.g. delete the personality function because ther's no way to get rid of its uses. Do this by resetting to ConstantPointerNull value that the operands are set to when first allocated.
Reviewers: vsk, dexonsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15752
llvm-svn: 256345
show more ...
|
#
3a63fb31 |
| 19-Dec-2015 |
Vedant Kumar <vsk@apple.com> |
Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thr
Re-reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences. Does not use binary literals.
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256095
show more ...
|
#
44dd9871 |
| 19-Dec-2015 |
Vedant Kumar <vsk@apple.com> |
Revert "Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist""
This reverts commit r256093.
This broke lld-x86_64-win7 because of -Werror,-Wc++1y-extensions.
llvm-svn: 256094
|
#
d481752e |
| 19-Dec-2015 |
Vedant Kumar <vsk@apple.com> |
Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thread
Reapply "[IR] Move optional data in llvm::Function into a hungoff uselist"
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Includes a fix to scrub value subclass data in dropAllReferences.
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256093
show more ...
|
#
e069c4b6 |
| 19-Dec-2015 |
Vedant Kumar <vsk@apple.com> |
Revert "[IR] Move optional data in llvm::Function into a hungoff uselist"
This reverts commit r256090.
This broke llvm-clang-lld-x86_64-debian-fast.
llvm-svn: 256091
|
#
be7525d4 |
| 19-Dec-2015 |
Vedant Kumar <vsk@apple.com> |
[IR] Move optional data in llvm::Function into a hungoff uselist
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thread "[RFC] Cl
[IR] Move optional data in llvm::Function into a hungoff uselist
Make personality functions, prefix data, and prologue data hungoff operands of Function.
This is based on the email thread "[RFC] Clean up the way we store optional Function data" on llvm-dev.
Thanks to sanjoyd, majnemer, rnk, loladiro, and dexonsmith for feedback!
Differential Revision: http://reviews.llvm.org/D13829
llvm-svn: 256090
show more ...
|
#
769efe62 |
| 02-Dec-2015 |
Rafael Espindola <rafael.espindola@gmail.com> |
Don't copy information from aliasee to alias.
They are independent.
llvm-svn: 254541
|
Revision tags: llvmorg-3.7.1 |
|
#
b8bb90b7 |
| 24-Nov-2015 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
Add vector types for intrinsics
Author: Ron Lieberman <ronl@codeaurora.org> llvm-svn: 253992
|
Revision tags: llvmorg-3.7.1-rc2 |
|
#
1ca72e18 |
| 19-Nov-2015 |
Elena Demikhovsky <elena.demikhovsky@intel.com> |
Pointers in Masked Load, Store, Gather, Scatter intrinsics
The masked intrinsics support all integer and floating point data types. I added the pointer type to this list. Added tests for CodeGen and
Pointers in Masked Load, Store, Gather, Scatter intrinsics
The masked intrinsics support all integer and floating point data types. I added the pointer type to this list. Added tests for CodeGen and for Loop Vectorizer. Updated the Language Reference.
Differential Revision: http://reviews.llvm.org/D14150
llvm-svn: 253544
show more ...
|
Revision tags: llvmorg-3.7.1-rc1 |
|
#
52888a67 |
| 08-Oct-2015 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
IR: Remove implicit iterator conversions from lib/IR, NFC
Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `
IR: Remove implicit iterator conversions from lib/IR, NFC
Stop converting implicitly between iterators and pointers/references in lib/IR. For convenience, I've added a `getIterator()` accessor to `ilist_node` so that callers don't need to know how to spell the iterator class (i.e., they can use `X.getIterator()` instead of `Function::iterator(X)`).
I'll eventually disallow these implicit conversions entirely, but there's a lot of code, so it doesn't make sense to do it all in one patch. One library or so at a time.
Why? To root out cases of `getNextNode()` and `getPrevNode()` being used in iterator logic. The design of `ilist` makes that invalid when the current node could be at the back of the list, but it happens to "work" right now because of a bug where those functions never return `nullptr` if you're using a half-node sentinel. Before I can fix the function, I have to remove uses of it that rely on it misbehaving. (Maybe the function should just be deleted anyway? But I don't want deleting it -- potentially a huge project -- to block fixing ilist/iplist.)
llvm-svn: 249782
show more ...
|
#
37bf678a |
| 07-Oct-2015 |
Duncan P. N. Exon Smith <dexonsmith@apple.com> |
IR: Create SymbolTableList wrapper around iplist, NFC
Create `SymbolTableList`, a wrapper around `iplist` for lists that automatically manage a symbol table. This commit reduces a ton of code dupli
IR: Create SymbolTableList wrapper around iplist, NFC
Create `SymbolTableList`, a wrapper around `iplist` for lists that automatically manage a symbol table. This commit reduces a ton of code duplication between the six traits classes that were used previously.
As a drive by, reduce the number of template parameters from 2 to 1 by using a SymbolTableListParentType metafunction (I originally had this as a separate commit, but it touched most of the same lines so I squashed them).
I'm in the process of trying to remove the UB in `createSentinel()` (see the FIXMEs I added for `ilist_embedded_sentinel_traits` and `ilist_half_embedded_sentinel_traits`). My eventual goal is to separate the list logic into a base class layer that knows nothing about (and isn't templated on) the downcasted nodes -- removing the need to invoke UB -- but for now I'm just trying to get a handle on all the current use cases (and cleaning things up as I see them).
Besides these six SymbolTable lists, there are two others that use the addNode/removeNode/transferNodes() hooks: the `MachineInstruction` and `MachineBasicBlock` lists. Ideally there'll be a way to factor these hooks out of the low-level API entirely, but I'm not quite there yet.
llvm-svn: 249602
show more ...
|
#
1ab5ea56 |
| 06-Oct-2015 |
Vedant Kumar <vsk@apple.com> |
[Function] Clean up {prefix,prologue} data routines (NFC)
Factor out some common code used to get+set function prefix/prologue data. This may come in handy if we ever decide to store personality fun
[Function] Clean up {prefix,prologue} data routines (NFC)
Factor out some common code used to get+set function prefix/prologue data. This may come in handy if we ever decide to store personality functions in the same way we store prefix/prologue data.
Differential Revision: http://reviews.llvm.org/D13120
Reviewed-by: bogner llvm-svn: 249460
show more ...
|
#
917c7382 |
| 02-Sep-2015 |
Joseph Tremoulet <jotrem@microsoft.com> |
[TableGen] Allow TokenTy in intrinsic signatures
Summary: Add the necessary plumbing so that llvm_token_ty can be used as an argument/return type in intrinsic definitions and correspondingly require
[TableGen] Allow TokenTy in intrinsic signatures
Summary: Add the necessary plumbing so that llvm_token_ty can be used as an argument/return type in intrinsic definitions and correspondingly require TokenTy in function types. TokenTy is an opaque type that has no target lowering, but can be used in machine-independent intrinsics. It is required for the upcoming llvm.eh.padparam intrinsic.
Reviewers: majnemer, rnk
Subscribers: stoklund, llvm-commits
Differential Revision: http://reviews.llvm.org/D12532
llvm-svn: 246651
show more ...
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4 |
|
#
d583b195 |
| 21-Aug-2015 |
David Blaikie <dblaikie@gmail.com> |
[opaque pointer types] Push the passing of value types up from Function/GlobalVariable to GlobalObject
(coming next, pushing this up into GlobalValue, so it can store the value type directly)
llvm-
[opaque pointer types] Push the passing of value types up from Function/GlobalVariable to GlobalObject
(coming next, pushing this up into GlobalValue, so it can store the value type directly)
llvm-svn: 245742
show more ...
|