This is the beginning of an effort to move the codeview yaml
reader / writer into ObjectYAML so that it can be shared.
Currently the only consumer / producer of CodeView YAML is
llvm-pdbdump, but CodeView can exist outside of PDB files, and
indeed is put into object files and passed to the linker to
produce PDB files. Furthermore, there are subtle differences
in the types of records that show up in object file CodeView
vs PDB file CodeView, but they are otherwise 99% the same.
By having this code in ObjectYAML, we can have llvm-pdbdump
reuse this code, while teaching obj2yaml and yaml2obj to use
this syntax for dealing with object files that can contain
CodeView.
This patch only adds support for CodeView type information
to ObjectYAML. Subsequent patches will add support for
CodeView symbol information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304248 91177308-0d34-0410-b5e6-96231b3b80d8
TargetPassConfig is not useful for targets that do not use the CodeGen
library, so we may just as well store a pointer to an
LLVMTargetMachine instead of just to a TargetMachine.
While at it, also change the constructor to take a reference instead of a
pointer as the TM must not be nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304247 91177308-0d34-0410-b5e6-96231b3b80d8
There is no guarantee that the first use of a constant that is traversed
is actually the first in the related basic block. Thus, if we use that
as the insertion point we may end up with definitions that don't
dominate there use.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304244 91177308-0d34-0410-b5e6-96231b3b80d8
This will fail if you configure with e.g. -Wno-unknown-warning-option.
Change it to check for 'warning:' just like we did for 'error:' in
r289484.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304239 91177308-0d34-0410-b5e6-96231b3b80d8
r303763 caused build failures in some out-of-tree tests due to an assertion in
TTI. The original patch updated cost estimates for induction variable update
instructions marked for scalarization. However, it didn't consider that the
incoming value of an induction variable phi node could be a cast instruction.
This caused queries for cast instruction costs with a mix of vector and scalar
types. This patch includes a fix for cast instructions and the test case from
PR33193.
The fix was suggested by Jonas Paulsson <paulsson@linux.vnet.ibm.com>.
Reference: https://bugs.llvm.org/show_bug.cgi?id=33193
Original Differential Revision: https://reviews.llvm.org/D33457
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304235 91177308-0d34-0410-b5e6-96231b3b80d8
Returning the Error by value triggers copy elision, the move is more
expensive. Clang rightfully warns about it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304232 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
In rL302576, DISubprograms gained the constraint that a !dbg attachments to functions must
have a 1:1 mapping to DISubprograms. As part of that change, the function cloning support
was adjusted to attempt to enforce this invariant during cloning. However, there
were several problems with the implementation. Part of these were fixed in rL304079.
However, there was a more fundamental problem with these changes, namely that it
bypasses the matadata value map, causing the cloned metadata to be a mix of metadata
pointing to the new suprogram (where manual code was added to fix those up) and the
old suprogram (where this was not the case). This mismatch could cause a number of
different assertion failures in the DWARF emitter. Some of these are given at
https://github.com/JuliaLang/julia/issues/22069, but some others have been observed
as well. Attempt to rectify this by partially reverting the manual DI metadata fixup,
and instead using the standard value map approach. To retain the desired semantics
of not duplicating the compilation unit and inlined subprograms, explicitly freeze
these in the value map.
Reviewers: dblaikie, aprantl, GorNishanov, echristo
Reviewed By: aprantl
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33655
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304226 91177308-0d34-0410-b5e6-96231b3b80d8
For multiplications of 64-bit values (giving 64-bit result), detect
cases where the arguments are sign-extended 32-bit values, on a per-
operand basis. This will allow few patterns to match a wider variety
of combinations in which extensions can occur.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304223 91177308-0d34-0410-b5e6-96231b3b80d8
This adds implementations for Symbols and FrameData, and renames
the existing codeview::StringTable class to conform to the
DebugSectionStringTable convention.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304222 91177308-0d34-0410-b5e6-96231b3b80d8
This code was compensating for FPOWI defaulting to Legal and many targets not changing it to Expand. This was fixed in r304215 to default to Expand so this special handling should no longer be necessary.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304221 91177308-0d34-0410-b5e6-96231b3b80d8
An encoding does not allow to use SDWA in an instruction with
scalar operands, either literals or SGPRs. That is however possible
to copy these operands into a VGPR first.
Several copies of the value are produced if multiple SDWA conversions
were done. To cleanup MachineLICM (to hoist copies out of loops),
MachineCSE (to remove duplicate copies) and SIFoldOperands (to replace
SGPR to VGPR copy with immediate copy right to the VGPR) runs are added
after the SDWA pass.
Differential Revision: https://reviews.llvm.org/D33583
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304219 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Currently FPOWI defaults to Legal and LegalizeDAG.cpp turns Legal into Expand for this opcode because Legal is a "lie".
This patch changes the default for this opcode to Expand and removes the hack from LegalizeDAG.cpp. It also removes all the code in the targets that set this opcode to Expand themselves since they can just rely on the default.
Reviewers: spatel, RKSimon, efriedma
Reviewed By: RKSimon
Subscribers: jfb, dschuff, sbc100, jgravelle-google, nemanjai, javed.absar, andrew.w.kaylor, llvm-commits
Differential Revision: https://reviews.llvm.org/D33530
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304215 91177308-0d34-0410-b5e6-96231b3b80d8
This adds assembler / disassembler support for the decimal
floating-point instructions. Since LLVM does not yet have
support for decimal float types, these cannot be used for
codegen at this point.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304203 91177308-0d34-0410-b5e6-96231b3b80d8
This adds assembler / disassembler support for the hexadecimal
floating-point instructions. Since the Linux ABI does not use
any hex float data types, these are not useful for codegen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304202 91177308-0d34-0410-b5e6-96231b3b80d8
A few instructions that are actually correctly supported in the
assembler and disassembler did not have any tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304200 91177308-0d34-0410-b5e6-96231b3b80d8
The MC ConstantPool class uses a DenseMap to track generated constants, with
the int64_t value of the constant as the key. This fails when values of
0x7fffffffffffffff or 0x7ffffffffffffffe are inserted into the constant pool, as
these are sentinel values for DenseMap.
The fix is to use std::map instead, which doesn't use sentinel values.
Differential revision: https://reviews.llvm.org/D33667
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304199 91177308-0d34-0410-b5e6-96231b3b80d8
This is super awkward, but GCC doesn't let us have template visible when
an argument is an inline function and -fvisibility-inlines-hidden is
used.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304175 91177308-0d34-0410-b5e6-96231b3b80d8
D33311 exposes the flakiness in this test. Replacing the undef placed by
bugpoint, makes it more interesting and robust.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304168 91177308-0d34-0410-b5e6-96231b3b80d8
They're now exposed as template args, which creates complications when
ManagedStatics are used across .so boundaries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304166 91177308-0d34-0410-b5e6-96231b3b80d8
Turns out this is very hostile towards other unit tests running in the
same process, it unregisters all flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304165 91177308-0d34-0410-b5e6-96231b3b80d8
xchg with a mem operand has different locking semantics. If we unfold it
into a xchg r,r we will loose the implicit lock. Likewise we never want
to fold a register xchg into a memory one as it would be a lot slower.
This triggers during LLVM selfhost.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304163 91177308-0d34-0410-b5e6-96231b3b80d8
error C2971: 'llvm::ManagedStatic': template parameter 'Creator': 'CreateDefaultTimerGroup': a variable with non-static storage duration cannot be used as a non-type argument
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304157 91177308-0d34-0410-b5e6-96231b3b80d8
This used to be just leaked. r295370 made it use magic statics. This adds
a global destructor, which is something we'd like to avoid. It also creates
a weird situation where the mutex used by TimerGroup is re-created during
global shutdown and leaked.
Using a ManagedStatic here is also subtle as it relies on the mutex
inside of ManagedStatic to be recursive. I've added a test for that
in a previous change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@304156 91177308-0d34-0410-b5e6-96231b3b80d8
