#
9f779195 |
| 21-Jun-2021 |
Nikita Popov <nikita.ppv@gmail.com> |
[OpaquePtr] Return opaque pointer from opaque pointer GEP
For a GEP on an opaque pointer, also return an opaque pointer (or vector of opaque pointer) result.
This requires explicitly enumerating th
[OpaquePtr] Return opaque pointer from opaque pointer GEP
For a GEP on an opaque pointer, also return an opaque pointer (or vector of opaque pointer) result.
This requires explicitly enumerating the GEP source element type, because it is now no longer implicitly enumerated as part of either the source or result pointer types.
Differential Revision: https://reviews.llvm.org/D104652
show more ...
|
Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
#
e5d844b5 |
| 21-Apr-2021 |
Stephen Tozer <Stephen.Tozer@Sony.com> |
[Bitcode] Ensure DIArgList in bitcode has no null or forward metadata refs
This patch fixes an issue in which ConstantAsMetadata arguments to a DIArglist, as well as the Constant values referenced b
[Bitcode] Ensure DIArgList in bitcode has no null or forward metadata refs
This patch fixes an issue in which ConstantAsMetadata arguments to a DIArglist, as well as the Constant values referenced by that metadata, would not be always be emitted correctly into bitcode. This patch fixes this issue firstly by searching for ConstantAsMetadata in DIArgLists (previously we would only search for them when directly wrapped in MetadataAsValue), and secondly by enumerating all of a DIArgList's arguments directly prior to enumerating the DIArgList itself.
This patch also adds a number of asserts, and no longer treats the arguments to a DIArgList as optional fields when reading/writing to bitcode.
Differential Revision: https://reviews.llvm.org/D100572
show more ...
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3 |
|
#
c79a4490 |
| 07-Mar-2021 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
OpaquePtr: Record byref types in bitcode writer
I missed this case when adding byref. I believe this is NFC until pointee types are really removed.
|
Revision tags: llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6 |
|
#
65600cb2 |
| 30-Sep-2020 |
gbtozers <stephen.tozer@sony.com> |
[DebugInfo] Add DIArgList MD to store multple values in DbgVariableIntrinsics
This patch adds a new metadata node, DIArgList, which contains a list of SSA values. This node is in many ways similar i
[DebugInfo] Add DIArgList MD to store multple values in DbgVariableIntrinsics
This patch adds a new metadata node, DIArgList, which contains a list of SSA values. This node is in many ways similar in function to the existing ValueAsMetadata node, with the difference being that it tracks a list instead of a single value. Internally, it uses ValueAsMetadata to track the individual values, but there is also a reasonable amount of DIArgList-specific value-tracking logic on top of that. Similar to ValueAsMetadata, it is a special case in parsing and printing due to the fact that it requires a function state (as it may reference function-local values).
This patch should not result in any immediate functional change; it allows for DIArgLists to be parsed and printed, but debug variable intrinsics do not yet recognize them as a valid argument (outside of parsing).
Differential Revision: https://reviews.llvm.org/D88175
show more ...
|
#
0c0fcea5 |
| 20-Oct-2020 |
David Stenberg <david.stenberg@ericsson.com> |
Handle value uses wrapped in metadata for the use-list order
When generating the use-list order, also consider value uses that are operands which are wrapped in metadata; e.g. llvm.dbg.value operand
Handle value uses wrapped in metadata for the use-list order
When generating the use-list order, also consider value uses that are operands which are wrapped in metadata; e.g. llvm.dbg.value operands.
This fixes PR36778. The test case is based on the reproducer from that report.
Reviewed By: dexonsmith
Differential Revision: https://reviews.llvm.org/D53758
show more ...
|
Revision tags: llvmorg-11.0.0-rc5 |
|
#
0a7cd99a |
| 29-Sep-2020 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
Reapply "OpaquePtr: Add type to sret attribute"
This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b.
Previously this was incorrectly handling linking of the contained type, so this merges
Reapply "OpaquePtr: Add type to sret attribute"
This reverts commit eb9f7c28e5fe6d75fed3587023e17f2997c8024b.
Previously this was incorrectly handling linking of the contained type, so this merges the fixes from D88973.
show more ...
|
Revision tags: llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
#
c6a82fdb |
| 16-Sep-2020 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
ValueEnumerator.cpp - remove duplicate includes. NFCI.
Remove headers already included in ValueEnumerator.h
|
Revision tags: llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
#
1647ff6e |
| 13-Apr-2020 |
Georgii Rymar <grimar@accesssoftek.com> |
[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers.
It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappe
[ADT/STLExtras.h] - Add llvm::is_sorted wrapper and update callers.
It can be used to avoid passing the begin and end of a range. This makes the code shorter and it is consistent with another wrappers we already have.
Differential revision: https://reviews.llvm.org/D78016
show more ...
|
#
1ee6ec2b |
| 31-Mar-2020 |
Eli Friedman <efriedma@quicinc.com> |
Remove "mask" operand from shufflevector.
Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and p
Remove "mask" operand from shufflevector.
Instead, represent the mask as out-of-line data in the instruction. This should be more efficient in the places that currently use getShuffleVector(), and paves the way for further changes to add new shuffles for scalable vectors.
This doesn't change the syntax in textual IR. And I don't currently plan to change the bitcode encoding in this patch, although we'll probably need to do something once we extend shufflevector for scalable types.
I expect that once this is finished, we can then replace the raw "mask" with something more appropriate for scalable vectors. Not sure exactly what this looks like at the moment, but there are a few different ways we could handle it. Maybe we could try to describe specific shuffles. Or maybe we could define it in terms of a function to convert a fixed-length array into an appropriate scalable vector, using a "step", or something like that.
Differential Revision: https://reviews.llvm.org/D72467
show more ...
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2 |
|
#
607c8a9d |
| 05-Jun-2019 |
Tim Northover <tnorthover@apple.com> |
IR: make getParamByValType Just Work. NFC.
Most parts of LLVM don't care whether the byval type is derived from an explicit Attribute or from the parameter's pointee type, so it makes sense for the
IR: make getParamByValType Just Work. NFC.
Most parts of LLVM don't care whether the byval type is derived from an explicit Attribute or from the parameter's pointee type, so it makes sense for the main access function to just return the right value.
The very few users who do care (only BitcodeReader so far) can find out how it's specified by accessing the Attribute directly.
llvm-svn: 362642
show more ...
|
#
b7141207 |
| 30-May-2019 |
Tim Northover <tnorthover@apple.com> |
Reapply: IR: add optional type to 'byval' function parameters
When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack.
Reapply: IR: add optional type to 'byval' function parameters
When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter.
If present, the type must match the pointee type of the argument.
The original commit did not remap byval types when linking modules, which broke LTO. This version fixes that.
Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change.
llvm-svn: 362128
show more ...
|
#
71ee3d02 |
| 29-May-2019 |
Tim Northover <tnorthover@apple.com> |
Revert "IR: add optional type to 'byval' function parameters"
The IRLinker doesn't delve into the new byval attribute when mapping types, and this breaks LTO.
llvm-svn: 362029
|
#
6e07f16f |
| 29-May-2019 |
Tim Northover <tnorthover@apple.com> |
IR: add optional type to 'byval' function parameters
When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds
IR: add optional type to 'byval' function parameters
When we switch to opaque pointer types we will need some way to describe how many bytes a 'byval' parameter should occupy on the stack. This adds a (for now) optional extra type parameter.
If present, the type must match the pointee type of the argument.
Note to front-end maintainers: if this causes test failures, it's probably because the "byval" attribute is printed after attributes without any parameter after this change.
llvm-svn: 362012
show more ...
|
Revision tags: llvmorg-8.0.1-rc1 |
|
#
3044ac05 |
| 07-May-2019 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
Avoid use-after-move warnings by using swap instead. NFCI.
Swap should be as quick in these cases, and leaves the original variables in a known (empty) state.
llvm-svn: 360164
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1 |
|
#
784929d0 |
| 08-Feb-2019 |
Craig Topper <craig.topper@intel.com> |
Implementation of asm-goto support in LLVM
This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
This patch adds a new CallBr IR instruction
Implementation of asm-goto support in LLVM
This patch accompanies the RFC posted here: http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
This patch adds a new CallBr IR instruction to support asm-goto inline assembly like gcc as used by the linux kernel. This instruction is both a call instruction and a terminator instruction with multiple successors. Only inline assembly usage is supported today.
This also adds a new INLINEASM_BR opcode to SelectionDAG and MachineIR to represent an INLINEASM block that is also considered a terminator instruction.
There will likely be more bug fixes and optimizations to follow this, but we felt it had reached a point where we would like to switch to an incremental development model.
Patch by Craig Topper, Alexander Ivchenko, Mikhail Dvoretckii
Differential Revision: https://reviews.llvm.org/D53765
llvm-svn: 353563
show more ...
|
Revision tags: llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
0cac726a |
| 27-Sep-2018 |
Fangrui Song <maskray@google.com> |
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscr
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
#
e0b5f86b |
| 10-May-2018 |
Vedant Kumar <vsk@apple.com> |
[STLExtras] Add distance() for ranges, pred_size(), and succ_size()
This commit adds a wrapper for std::distance() which works with ranges. As it would be a common case to write `distance(predecesso
[STLExtras] Add distance() for ranges, pred_size(), and succ_size()
This commit adds a wrapper for std::distance() which works with ranges. As it would be a common case to write `distance(predecessors(BB))`, this also introduces `pred_size()` and `succ_size()` helpers to make that easier to write.
Differential Revision: https://reviews.llvm.org/D46668
llvm-svn: 332057
show more ...
|
#
432a3883 |
| 30-Apr-2018 |
Nico Weber <nicolasweber@gmx.de> |
IWYU for llvm-config.h in llvm, additions.
See r331124 for how I made a list of files missing the include. I then ran this Python script:
for f in open('filelist.txt'): f = f.strip()
IWYU for llvm-config.h in llvm, additions.
See r331124 for how I made a list of files missing the include. I then ran this Python script:
for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines()
found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl))
and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot.
No intended behavior change.
llvm-svn: 331184
show more ...
|
Revision tags: llvmorg-6.0.1-rc1 |
|
#
176c3efa |
| 05-Apr-2018 |
Mandeep Singh Grang <mgrang@codeaurora.org> |
[Bitcode] Change std::sort to llvm::sort in response to r327219
Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-det
[Bitcode] Change std::sort to llvm::sort in response to r327219
Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches.
Reviewers: pcc, mehdi_amini, dexonsmith
Reviewed By: dexonsmith
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45132
llvm-svn: 329334
show more ...
|
Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1 |
|
#
615eb470 |
| 15-Oct-2017 |
Aaron Ballman <aaron@aaronballman.com> |
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.
Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.
Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1
llvm-svn: 315854
show more ...
|
#
3e0199f7 |
| 12-Oct-2017 |
Don Hinton <hintonda@gmail.com> |
[dump] Remove NDEBUG from test to enable dump methods [NFC]
Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and
[dump] Remove NDEBUG from test to enable dump methods [NFC]
Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
show more ...
|
#
975293f0 |
| 07-Sep-2017 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
[Bitcode] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 312760
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
#
8bf67fe9 |
| 23-May-2017 |
Reid Kleckner <rnk@google.com> |
[IR] Switch AttributeList to use an array for O(1) access
Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have
[IR] Switch AttributeList to use an array for O(1) access
Summary: Before this change, AttributeLists stored a pair of index and AttributeSet. This is memory efficient if most arguments do not have attributes. However, it requires doing a search over the pairs to test an argument or function attribute. Profiling shows that this loop was 0.76% of the time in 'opt -O2' of sqlite3.c, because LLVM constantly tests values for nullability.
This was worth about 2.5% of mid-level optimization cycles on the sqlite3 amalgamation. Here are the full perf results: https://reviews.llvm.org/P7995
Here are just the before and after cycle counts: ``` $ perf stat -r 5 ./opt_before -O2 sqlite3.bc -o /dev/null 13,274,181,184 cycles # 3.047 GHz ( +- 0.28% ) $ perf stat -r 5 ./opt_after -O2 sqlite3.bc -o /dev/null 12,906,927,263 cycles # 3.043 GHz ( +- 0.51% ) ```
This patch *does not* change the indices used to query attributes, as requested by reviewers. Tracking whether an index is usable for array indexing is a huge pain that affects many of the internal APIs, so it would be good to come back later and do a cleanup to remove this internal adjustment.
Reviewers: pete, chandlerc
Subscribers: javed.absar, llvm-commits
Differential Revision: https://reviews.llvm.org/D32819
llvm-svn: 303654
show more ...
|
#
f3d7904d |
| 11-May-2017 |
Javed Absar <javed.absar@arm.com> |
[IR] Allow attributes with global variables
This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.
[IR] Allow attributes with global variables
This patch extends llvm-ir to allow attributes to be set on global variables. An RFC was sent out earlier by my colleague James Molloy: http://lists.llvm.org/pipermail/cfe-dev/2017-March/053100.html A key part of that proposal was to extend LLVM-IR to carry attributes on global variables. This generic feature could be useful for multiple purposes. In our present context, it would be useful to carry user specified sections for bss/rodata/data.
Reviewed by: Jonathan Roelofs, Reid Kleckner Differential Revision: https://reviews.llvm.org/D32009
llvm-svn: 302794
show more ...
|