| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
CloneModule"
Apparently, DebugInfoFinder::processCompileUnit doesn't process all
of the possible kinds of DIImportedEntit'ies, e.g. DIGlobalVariable's.
Previously introduced `llvm_unreachable` is therefore incorrect.
Removing it here.
llvm-svn: 330167
|
| |
|
|
|
|
|
|
|
| |
Using Config->is64() will treat ARM64 as Amd64, which is incorrect.
Furthermore, there are more esoteric architectures that could
theoretically be encountered. Just set it directly to the machine
type, which we already know anyway.
llvm-svn: 330157
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Specifying assert message with an || operator makes the compiler interpret it
as a bool. Changed it to &&.
Reviewers: asb, apazos
Reviewed By: asb
Subscribers: rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, llvm-commits
Differential Revision: https://reviews.llvm.org/D45660
llvm-svn: 330148
|
| |
|
|
|
|
|
| |
This fixes the failing tests. They simply hadn't been updated
to match the new output resulting from this patch.
llvm-svn: 330145
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
extractelement/ext pair
We use getExtractWithExtendCost to calculate the cost of extractelement and
s|zext together when computing the extract cost after vectorization, but we
calculate the cost of extractelement and s|zext separately when computing the
scalar cost which is larger than it should be.
Differential Revision: https://reviews.llvm.org/D45469
llvm-svn: 330143
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
materializing function definitions.
MaterializationUnit instances are responsible for resolving and finalizing
symbol definitions when their materialize method is called. By contract, the
MaterializationUnit must materialize all definitions it is responsible for and
no others. If it can not materialize all definitions (because of some error)
then it must notify the associated VSO about each definition that could not be
materialized. The MaterializationResponsibility class tracks this
responsibility, asserting that all required symbols are resolved and finalized,
and that no extraneous symbols are resolved or finalized. In the event of an
error it provides a convenience method for notifying the VSO about each
definition that could not be materialized.
llvm-svn: 330142
|
| |
|
|
|
|
|
|
|
| |
notifyMaterializationFailed.
The notifyMaterializationFailed method can determine which error to raise by
looking at which queue the pending queries are in (resolution or finalization).
llvm-svn: 330141
|
| |
|
|
|
|
| |
It was turned on for testing and was accidentally left on in the commit.
llvm-svn: 330139
|
| |
|
|
|
|
|
| |
Move veriication check for legal conversions to f128 into LowerINT_TO_FP()
and fix some indentations to match other sections of the code for readability.
llvm-svn: 330138
|
| |
|
|
| |
llvm-svn: 330137
|
| |
|
|
|
|
|
|
|
|
| |
FunctionIndex and ReturnIndex/arg indices at the same time
The code uses the index of the last element in the sorted array to determine the maximum size needed for the vector. But if the last index is a FunctionIndex(~0), attrIdxToArrayIdx will return 0 and the vector will have size 1. If there are any indices before FunctionIndex, those values would return a value larger than 0 from attrIdxToArrayIdx. So in this case we need to look in front of the FunctionIndex to get the true size needed.
Differential Revision: https://reviews.llvm.org/D45632
llvm-svn: 330136
|
| |
|
|
|
|
|
| |
There are a couple of failing tests which slipped under my radar
so I'm reverting this while I attempt to fix.
llvm-svn: 330133
|
| |
|
|
|
|
|
|
|
|
|
| |
When emitting CodeView debug information, compiler-generated thunk routines
should be emitted using S_THUNK32 symbols instead of S_GPROC32_ID symbols so
Visual Studio can properly step into the user code. This initial support only
handles standard thunk ordinals.
Differential Revision: https://reviews.llvm.org/D43838
llvm-svn: 330132
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Most of these are pretty trivial and obvious. Setting the toolchain
version to 14.11 is perhaps a little questionable, but we've been bitten
in the past where one of our version fields sidn't match MSVC's, and I
definitely don't want to go through that diagnosis again as it was
pretty time consuming and hard to track down.
I found all of these by using llvm-pdbutil export to dump the dbi and
pdb streams to a file, then using fc followed by llvm-pdbutil explain to
explain the mismatched bytes.
There are still some more, these are just the low hanging fruit.
Differential Revision: https://reviews.llvm.org/D45276
llvm-svn: 330130
|
| |
|
|
| |
llvm-svn: 330129
|
| |
|
|
|
|
|
|
| |
Two cleanups:
1. As noted in D45453, we had tests that don't need FMF that were misplaced in the 'fast-math.ll' test file.
2. This removes the final uses of dyn_castFNegVal, so that can be deleted. We use 'match' now.
llvm-svn: 330126
|
| |
|
|
| |
llvm-svn: 330124
|
| |
|
|
|
|
|
|
|
| |
See bug 36356: https://bugs.llvm.org/show_bug.cgi?id=36356
Differential Revision: https://reviews.llvm.org/D45446
Reviewers: artem.tamazov, arsenm, timcorringham
llvm-svn: 330123
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro
Reviewed By: rengolin
Subscribers: tschuett, llvm-commits, kristof.beyls
Differential Revision: https://reviews.llvm.org/D45624
llvm-svn: 330120
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro
Reviewed By: rengolin
Subscribers: tschuett, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45623
llvm-svn: 330116
|
| |
|
|
|
|
|
|
|
| |
Instructions removed from micromipsr6:
teqi, tgei, tgeiu, tlti, tltiu, tnei
Differential Revision: https://reviews.llvm.org/D45318
llvm-svn: 330114
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Transforms the following:
%vreg1234:gpr32 = COPY %42
%vreg1235:gpr32 = COPY %vreg1234
%vreg1236:gpr32 = COPY %vreg1235
$w0 = COPY %vreg1236
into:
$w0 = COPY %42
Assuming %42 is also a gpr32
llvm-svn: 330113
|
| |
|
|
| |
llvm-svn: 330111
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using Goldmont's cost tables for these two upcoming
atom archs.
Reviewers: craig.topper
Reviewed By: craig.topper
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45612
llvm-svn: 330109
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: fhahn, rengolin, javed.absar, huntergr, SjoerdMeijer, t.p.northover, echristo, evandro
Reviewed By: rengolin
Subscribers: tschuett, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D45622
llvm-svn: 330108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As discussed in https://reviews.llvm.org/D45606, it makes more sense to name the class as SmallVectorMemoryBuffer
Reviewers: bkramer, dblaikie
Reviewed By: dblaikie
Subscribers: mehdi_amini, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D45661
llvm-svn: 330107
|
| |
|
|
|
|
|
|
| |
structure object member
Differential Revision: https://reviews.llvm.org/D45510
llvm-svn: 330106
|
| |
|
|
|
|
| |
of an APInt value. NFC
llvm-svn: 330105
|
| |
|
|
|
|
| |
GetLo8XForm right next to it uses uint8_t so uint32_t is consistent.
llvm-svn: 330104
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In order to get the whole fold as specified in [[ https://bugs.llvm.org/show_bug.cgi?id=6773 | PR6773 ]],
let's first handle the simple straight-forward things.
Let's start with the `and` -> `or` simplification.
The one obvious thing missing here: the constant mask is not handled.
I have an idea how to handle it, but it will require some thinking,
and is not strictly required here, so i've left that for later.
https://rise4fun.com/Alive/Pkmg
Reviewers: spatel, craig.topper, eli.friedman, jingyue
Reviewed By: spatel
Subscribers: llvm-commits
Was reviewed as part of https://reviews.llvm.org/D45631
llvm-svn: 330103
|
| |
|
|
|
|
| |
As suggested in https://reviews.llvm.org/D45631#1068338
llvm-svn: 330102
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In order to get the whole fold as specified in [[ https://bugs.llvm.org/show_bug.cgi?id=6773 | PR6773 ]],
let's first handle the simple straight-forward things.
Let's start with the `and` -> `or` simplification.
The one obvious thing missing here: the constant mask is not handled.
I have an idea how to handle it, but it will require some thinking,
and is not strictly required here, so i've left that for later.
https://rise4fun.com/Alive/Pkmg
Reviewers: spatel, craig.topper, eli.friedman, jingyue
Reviewed By: spatel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45631
llvm-svn: 330101
|
| |
|
|
|
|
|
|
| |
As suggested in https://reviews.llvm.org/D45631#1068338,
looking at haveNoCommonBitsSet() users, and *trying* to
show the change effect elsewhere.
llvm-svn: 330100
|
| |
|
|
|
|
|
|
|
|
| |
reciprocal throughput from TargetSchedModel to MCSchedModel.
TargetSchedModel now always delegates to MCSchedModel the computation of
instruction latency and reciprocal throughput.
No functional change intended.
llvm-svn: 330099
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a transform that I limited in instcombine in rL329821 because it was
creating more instructions in IR when the cast has multiple uses.
But if the cast is free, then we can do the transform regardless of other
uses because it improves the potential throughput of the calculation by
removing a dependency on the fneg.
Differential Revision: https://reviews.llvm.org/D45598
llvm-svn: 330098
|
| |
|
|
|
|
|
| |
Also, fix capitalization to current style. Follow-up to:
rL330096
llvm-svn: 330097
|
| |
|
|
| |
llvm-svn: 330096
|
| |
|
|
|
|
|
| |
Although printing warnings and errors to stderr is by far the most
common case, this patch makes it possible to specify any stream.
llvm-svn: 330094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Since the class is used by both MCJIT and LTO, it makes more sense to move it to Support lib.
This is a follow up patch to r329929 and https://reviews.llvm.org/D45244
Reviewers: bkramer, dblaikie
Reviewed By: bkramer
Subscribers: mehdi_amini, eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D45606
llvm-svn: 330093
|
| |
|
|
|
|
|
| |
Use the convenience methods from WithColor to consistently print errors
and warnings in libDebugInfo.
llvm-svn: 330092
|
| |
|
|
|
|
|
|
|
| |
Create convenience functions for printing error, warning and note to
stdout. Previously we had similar functions being used in dsymutil, but
given that this pattern is so common it makes sense to make it available
globally.
llvm-svn: 330091
|
| |
|
|
|
|
|
|
| |
These simplifications were previously enabled only with isFast(), but that
is more restrictive than required. Since r317488, FMF has 'reassoc' to
control these cases at a finer level.
llvm-svn: 330089
|
| |
|
|
|
|
| |
classes as SSE/AVX
llvm-svn: 330085
|
| |
|
|
|
|
| |
"not not" -> "not" etc
llvm-svn: 330083
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
InsertPos is within the bacic block `Header`, so `findDebugLoc()` should
be called on not `MBB` but `Header` instead.
Reviewers: yurydelendik
Subscribers: jfb, dschuff, aprantl, sbc100, jgravelle-google, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45648
llvm-svn: 330079
|
| |
|
|
|
|
|
|
| |
The destination size of the movzx/movsx instruction is controlled by the normal operand size mechanisms. Only the input type is fixed.
This means that a 0x66 prefix on the encoding for zext/sext 16->32 should really produce a 16->16 instruction. Functionally this is equivalent to a GR16->GR16 move since bits 16 and above will be preserved. So nothing is actually extended.
llvm-svn: 330078
|
| |
|
|
|
|
|
| |
Debugability is more important than saving 4 bytes to let us to fall
through to nonense.
llvm-svn: 330073
|
| |
|
|
|
|
| |
CloneModule"
llvm-svn: 330070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As demonstrated by the regression tests added in this patch, the
following cases are valid cases:
1. A Function with no DISubprogram attached, but various debug info
related to its instructions, coming, for instance, from an inlined
function, also defined somewhere else in the same module;
2. ... or coming exclusively from the functions inlined and eliminated
from the module entirely.
The ValueMap shared between CloneFunctionInto calls within CloneModule
needs to contain identity mappings for all of the DISubprogram's to
prevent them from being duplicated by MapMetadata / RemapInstruction
calls, this is achieved via DebugInfoFinder collecting all the
DISubprogram's. However, CloneFunctionInto was missing calls into
DebugInfoFinder for functions w/o DISubprogram's attached, but still
referring DISubprogram's from within (case 1). This patch fixes that.
The fix above, however, exposes another issue: if a module contains a
DISubprogram referenced only indirectly from other debug info
metadata, but not attached to any Function defined within the module
(case 2), cloning such a module causes a DICompileUnit duplication: it
will be moved in indirecty via a DISubprogram by DebugInfoFinder first
(because of the first bug fix described above), without being
self-mapped within the shared ValueMap, and then will be copied during
named metadata cloning. So this patch makes sure DebugInfoFinder
visits DICompileUnit's referenced from DISubprogram's as it goes w/o
re-processing llvm.dbg.cu list over and over again for every function
cloned, and makes sure that CloneFunctionInto self-maps
DICompileUnit's referenced from the entire function, not just its own
DISubprogram attached that may also be missing.
The most convenient way of tesing CloneModule I found is to rely on
CloneModule call from `opt -run-twice`, instead of writing tedious
unit tests. That feature has a couple of properties that makes it hard
to use for this purpose though:
1. CloneModule doesn't copy source filename, making `opt -run-twice`
report it as a difference.
2. `opt -run-twice` does the second run on the original module, not
its clone, making the result of cloning completely invisible in opt's
actual output with and without `-run-twice` both, which directly
contradicts `opt -run-twice`s own error message.
This patch fixes this as well.
Reviewed By: aprantl
Reviewers: loladiro, GorNishanov, espindola, echristo, dexonsmith
Subscribers: vsk, debug-info, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D45593
llvm-svn: 330069
|
| |
|
|
| |
llvm-svn: 330065
|