| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21624
llvm-svn: 273692
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 273686
|
| |
|
|
|
|
| |
Intrinsic::matchIntrinsicVarArg since it will be reused for intrinsic remangling code
llvm-svn: 273685
|
| |
|
|
|
|
| |
It broke 2008-07-15-Bswap.ll and 2009-09-01-PostRAProlog.ll
llvm-svn: 273574
|
| |
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 273568
|
| |
|
|
|
|
| |
and selects.
llvm-svn: 273543
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is a convenience iterator that allows clients to enumerate the
GlobalObjects within a Module.
Also start using it in a few places where it is obviously the right thing
to use.
Differential Revision: http://reviews.llvm.org/D21580
llvm-svn: 273470
|
| |
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 273424
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
issue with globals.
This change is motivated by an upcoming change to the metadata representation
used for CFI. The indirect function call checker needs type information for
external function declarations in order to correctly generate jump table
entries for such declarations. We currently associate such type information
with declarations using a global metadata node, but I plan [1] to move all
such metadata to global object attachments.
In bitcode, metadata attachments for function declarations appear in the
global metadata block. This seems reasonable to me because I expect metadata
attachments on declarations to be uncommon. In the long term I'd also expect
this to be the case for CFI, because we'd want to use some specialized bitcode
format for this metadata that could be read as part of the ThinLTO thin-link
phase, which would mean that it would not appear in the global metadata block.
To solve the lazy loaded metadata issue I was seeing with D20147, I use the
same bitcode representation for metadata attachments for global variables as I
do for function declarations. Since there's a use case for metadata attachments
in the global metadata block, we might as well use that representation for
global variables as well, at least until we have a mechanism for lazy loading
global variables.
In the assembly format, the metadata attachments appear after the "declare"
keyword in order to avoid a parsing ambiguity.
[1] http://lists.llvm.org/pipermail/llvm-dev/2016-June/100462.html
Differential Revision: http://reviews.llvm.org/D21052
llvm-svn: 273336
|
| |
|
|
|
|
| |
native icmps.
llvm-svn: 273240
|
| |
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19185
llvm-svn: 273203
|
| |
|
|
|
|
|
| |
Backends may want to report errors on resources other than
stack size.
llvm-svn: 273177
|
| |
|
|
| |
llvm-svn: 273118
|
| |
|
|
|
|
| |
Required better annotation of the instruction defs upon removal of the builtin intrinsic pattern.
llvm-svn: 273077
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This seems like the least intrusive way to pass this information
through.
Fixes PR28151
Reviewers: majnemer, aprantl, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21444
llvm-svn: 273053
|
| |
|
|
|
|
|
|
|
| |
We convert `Default` to `NotPIC` so that target independent code
can reason about this correctly.
Differential Revision: http://reviews.llvm.org/D21394
llvm-svn: 273024
|
| |
|
|
|
|
|
| |
prior to some very substantial patches to isolate any formatting-only
changes.
llvm-svn: 272991
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pass manager passes' `run` methods.
This removes a bunch of SFINAE goop from the pass manager and just
requires pass authors to accept `AnalysisManager<IRUnitT> &` as a dead
argument. This is a small price to pay for the simplicity of the system
as a whole, despite the noise that changing it causes at this stage.
This will also helpfull allow us to make the signature of the run
methods much more flexible for different kinds af passes to support
things like intelligently updating the pass's progression over IR units.
While this touches many, many, files, the changes are really boring.
Mostly made with the help of my trusty perl one liners.
Thanks to Sean and Hal for bouncing ideas for this with me in IRC.
llvm-svn: 272978
|
| |
|
|
|
|
|
| |
This will (hopefully very temporarily) break clang.
The clang side of this should be the next commit.
llvm-svn: 272932
|
| |
|
|
|
|
|
|
| |
Follow-up to:
http://reviews.llvm.org/rL272806
http://reviews.llvm.org/rL272807
llvm-svn: 272907
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GlobalObject::copyAttributesFrom.
Summary: This reverts the changes to Globals.cpp and IRMover.cpp in
"[IR] Copy comdats in GlobalObject::copyAttributesFrom" (D20631,
rL270743).
The DeadArgElim test is left unchanged, and we change DAE to explicitly
copy comdats.
The reverted change breaks copyAttributesFrom when the destination lives
in a different module from the source. The decision in D21255 was to
revert this patch and handle comdat copying separately from
copyAttributesFrom.
Reviewers: majnemer, rnk
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D21403
llvm-svn: 272855
|
| |
|
|
| |
llvm-svn: 272848
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 272811
|
| |
|
|
|
|
| |
warning from MSVC.
llvm-svn: 272793
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: The second consumer of attributes.
Reviewers: Wallbraker, whitequark, echristo, rafael, jyknight
Subscribers: mehdi_amini
Differential Revision: http://reviews.llvm.org/D21266
llvm-svn: 272754
|
| |
|
|
| |
llvm-svn: 272734
|
| |
|
|
| |
llvm-svn: 272731
|
| |
|
|
|
|
|
|
|
|
|
|
| |
reflect that they work on slots rather than attributes. NFC
Summary: The current naming not only doesn't convey the meaning of what this does, but worse, it convey the wrong meaning. This was a major source of confusion understanding the code, so I'm applying the boy scout rule here and making it better after I leave.
Reviewers: void, bkramer, whitequark
Differential Revision: http://reviews.llvm.org/D21264
llvm-svn: 272725
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a local_unnamed_addr attribute is attached to a global, the address
is known to be insignificant within the module. It is distinct from the
existing unnamed_addr attribute in that it only describes a local property
of the module rather than a global property of the symbol.
This attribute is intended to be used by the code generator and LTO to allow
the linker to decide whether the global needs to be in the symbol table. It is
possible to exclude a global from the symbol table if three things are true:
- This attribute is present on every instance of the global (which means that
the normal rule that the global must have a unique address can be broken without
being observable by the program by performing comparisons against the global's
address)
- The global has linkonce_odr linkage (which means that each linkage unit must have
its own copy of the global if it requires one, and the copy in each linkage unit
must be the same)
- It is a constant or a function (which means that the program cannot observe that
the unique-address rule has been broken by writing to the global)
Although this attribute could in principle be computed from the module
contents, LTO clients (i.e. linkers) will normally need to be able to compute
this property as part of symbol resolution, and it would be inefficient to
materialize every module just to compute it.
See:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html
for earlier discussion.
Part of the fix for PR27553.
Differential Revision: http://reviews.llvm.org/D20348
llvm-svn: 272709
|
| |
|
|
|
|
| |
consistently. Historically they used to be the same the terminology is very confused in the codebase. NFC.
llvm-svn: 272704
|
| |
|
|
|
|
| |
autoupgrade them to selects and shufflevector.
llvm-svn: 272527
|
| |
|
|
|
|
| |
select generation into routines that can be reused for future intrinsic upgrades. NFC
llvm-svn: 272526
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
td_type is std::pair<std::string, std::string>, but the map returns
elements of std::pair<const std::string, std::string>. In well-designed
languages like C++ that yields an implicit copy perfectly hidden by
constref's lifetime extension. Just use auto, the typedef obscured the
real type anyways.
Found with a little help from clang-tidy's
performance-implicit-cast-in-loop.
llvm-svn: 272519
|
| |
|
|
| |
llvm-svn: 272517
|
| |
|
|
|
|
| |
shufflevector.
llvm-svn: 272510
|
| |
|
|
| |
llvm-svn: 272506
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 272504
|
| |
|
|
|
|
| |
code instead of calling push_back in a loop. This removes the need to check if the vector needs to grow on each iteration.
llvm-svn: 272501
|
| |
|
|
|
|
| |
fully derive everything using types of the intrinsic arguments rather than writing separate loops for each intrinsic. NFC
llvm-svn: 272496
|
| |
|
|
|
|
| |
ArrayRef<uint32_t> to avoid the need to manually create a bunch of Constants and a ConstantVector. NFC
llvm-svn: 272493
|
| |
|
|
|
|
| |
for one of the signatures of CreateShuffleVector. This better emphasises that you can't use it for the -1 as undef behavior.
llvm-svn: 272491
|
| |
|
|
|
|
| |
(This is split out from was D21115)
llvm-svn: 272435
|
| |
|
|
|
|
| |
Auto-upgrade to generic shuffles like sse/avx2 implementations now that we can lower to VPSLLDQ/VPSRLDQ
llvm-svn: 272308
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Now DISubroutineType has a 'cc' field which should be a DW_CC_ enum. If
it is present and non-zero, the backend will emit it as a
DW_AT_calling_convention attribute. On the CodeView side, we translate
it to the appropriate enum for the LF_PROCEDURE record.
I added a new LLVM vendor specific enum to the list of DWARF calling
conventions. DWARF does not appear to attempt to standardize these, so I
assume it's OK to do this until we coordinate with GCC on how to emit
vectorcall convention functions.
Reviewers: dexonsmith, majnemer, aaboud, amccarth
Subscribers: mehdi_amini, llvm-commits
Differential Revision: http://reviews.llvm.org/D21114
llvm-svn: 272197
|
| |
|
|
|
|
|
|
| |
As suggested by clang-tidy's performance-unnecessary-copy-initialization.
This can easily hit lifetime issues, so I audited every change and ran the
tests under asan, which came back clean.
llvm-svn: 272126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions.
Arrange to call verify(Function &) on each function, followed by
verify(Module &), whether the verifier is being used from the pass or
from verifyModule(). As a side effect, this fixes an issue that caused
us not to call verify(Function &) on unmaterialized functions from
verifyModule().
Differential Revision: http://reviews.llvm.org/D21042
llvm-svn: 271956
|
| |
|
|
|
|
|
| |
Remove previously unreachable code that verifies that a function definition has
an entry block. By definition, a function definition has at least one block.
llvm-svn: 271948
|
| |
|
|
|
|
| |
of vector shuffle and select.
llvm-svn: 271872
|
| |
|
|
| |
llvm-svn: 271862
|
| |
|
|
| |
llvm-svn: 271745
|