| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 230185
|
| |
|
|
|
|
|
|
|
|
| |
This increases the flexibility of how to dump different
symbol types -- necessary for context-sensitive formatting of
symbol types -- and also improves the modularity by allowing
the dumping to be implemented in the actual dumper, as opposed
to in the PDB library.
llvm-svn: 230184
|
| |
|
|
|
|
|
|
|
| |
This removes a wealth of options, and instead now only provides
three options. -symbols, -types, and -compilands. This greatly
simplifies use of the tool, and makes it easier to understand
what you're going to see when you run the tool.
llvm-svn: 230182
|
| |
|
|
|
|
| |
the inevitable "unused variable" warning in a non-asserts build.
llvm-svn: 230181
|
| |
|
|
|
|
|
|
|
|
| |
While fuzzing LLVM bitcode files, I discovered that (1) the bitcode reader doesn't check that alignments are no larger than 2**29; (2) downstream code doesn't check the range; and (3) for values out of range, corresponding large memory requests (based on alignment size) will fail. This code fixes the bitcode reader to check for valid alignments, fixing this problem.
This CL fixes alignment value on global variables, functions, and instructions: alloca, load, load atomic, store, store atomic.
Patch by Karl Schimpf (kschimpf@google.com).
llvm-svn: 230180
|
| |
|
|
|
|
|
|
|
|
|
| |
This refactors the core functionality of LICM: HoistRegion, SinkRegion and
PromoteAliasSet (renamed to promoteLoopAccessesToScalars) as utility functions
in LoopUtils. This will enable other transformations to make use of them
directly.
Patch by Ashutosh Nema.
llvm-svn: 230178
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The CONCAT_VECTORS combiner pass can transform the concat of two BUILD_VECTOR nodes into a single BUILD_VECTOR node.
This patch generalises this to support any number of BUILD_VECTOR nodes, and also permits UNDEF nodes to be included as well.
This was noticed as AVX vec128 -> vec256 canonicalization sometimes creates a CONCAT_VECTOR with a real vec128 lower and an vec128 UNDEF upper.
Differential Revision: http://reviews.llvm.org/D7816
llvm-svn: 230177
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reduceBuildVecConvertToConvertBuildVec
DAGCombine will rewrite an BUILD_VECTOR where all non-undef inputs some from
[US]INT_TO_FP, as a BUILD_VECTOR of integers with the conversion applied as a
vector operation. We check operation legality of the conversion, but fail to
check legality of the integer vector type itself. Because targets don't
normally override operation legality defaults for illegal types, we need to
check this also.
This came up in the context of the QPX vector entensions for PowerPC (which can
have legal floating-point vector types without corresponding legal integer
vector types). No in-tree test case for this yes, but one can be added once
the QPX support has been committed.
llvm-svn: 230176
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When expanding a truncating store or extending load using vector extracts or
inserts and scalar stores and loads, we were giving each of these scalar stores
or loads the same alignment as the original vector operation. While this will
often be right (most vector operations, especially those produced by
autovectorization, have the alignment of the underlying scalar type), the
vector operation could certainly have a larger alignment.
No test case (yet); noticed by inspection.
llvm-svn: 230175
|
| |
|
|
| |
llvm-svn: 230170
|
| |
|
|
|
|
| |
LLVM_ATTRIBUTE_UNUSED. [-Wunused-function]
llvm-svn: 230169
|
| |
|
|
| |
llvm-svn: 230168
|
| |
|
|
|
|
| |
\param should be used as itemized.
llvm-svn: 230167
|
| |
|
|
| |
llvm-svn: 230165
|
| |
|
|
|
|
| |
The bots seem to be happy now.
llvm-svn: 230164
|
| |
|
|
|
|
|
| |
I was setting the python variable to "@HAVE_DIA_SDK@", which will
always be a string, and will always evaluate to True.
llvm-svn: 230163
|
| |
|
|
|
|
|
|
| |
The issue was that the test Makefile had not been updated to
provide a value for HAVE_DIA_SDK, so it was being initialized
incorrectly. Hopefully this brings everything back to green.
llvm-svn: 230162
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: This patch intentionally breaks the build. It attempts
to resubmit r230083, but with some debug logging in the CMake
and lit config files to determine why certain bots do not
correctly disable the DIA tests when DIA is not available.
After a sufficient number of bots fail, this patch will either
be reverted or, if the cause of the failure becomes obvious,
a fix submitted with the log statements removed.
llvm-svn: 230161
|
| |
|
|
|
|
|
| |
The CodeView debug info section, .debug$S, also has this set. MinGW
sets this bit for their DWARF sections as well.
llvm-svn: 230156
|
| |
|
|
| |
llvm-svn: 230155
|
| |
|
|
| |
llvm-svn: 230154
|
| |
|
|
| |
llvm-svn: 230153
|
| |
|
|
|
|
|
|
|
|
| |
work with a non-canonical induction variable.
This is currently a non-functional change because we only ever call
computeSafeIterationSpace on a canonical induction variable; but the
generalization will be useful in a later commit.
llvm-svn: 230151
|
| |
|
|
|
|
|
|
|
| |
calculations. Semantically non-functional change.
This gets rid of some of the SCEV -> Value -> SCEV round tripping and
the Construct(SMin|SMax)Of and MaybeSimplify helper routines.
llvm-svn: 230150
|
| |
|
|
| |
llvm-svn: 230149
|
| |
|
|
|
|
|
| |
This is a code size optimization when the constant
only has one use.
llvm-svn: 230148
|
| |
|
|
| |
llvm-svn: 230147
|
| |
|
|
| |
llvm-svn: 230146
|
| |
|
|
| |
llvm-svn: 230145
|
| |
|
|
|
|
| |
Patch by Rob Stewart. Thanks!
llvm-svn: 230144
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 230143
|
| |
|
|
| |
llvm-svn: 230142
|
| |
|
|
|
|
|
| |
While it's not POD due to the user-defined constructor, it's still a trivially
copyable type. No functional change.
llvm-svn: 230141
|
| |
|
|
| |
llvm-svn: 230137
|
| |
|
|
|
|
|
| |
This was just replicating logic from the legalizer. Covered by existing
tests.
llvm-svn: 230136
|
| |
|
|
|
|
|
|
| |
asm parsing since it's not subtarget dependent and we can't depend
upon the one hanging off the MachineFunction's subtarget still
being around.
llvm-svn: 230135
|
| |
|
|
| |
llvm-svn: 230134
|
| |
|
|
|
|
|
| |
MCSubtargetInfo as the MachineFunction has gone away and we need
to emit code at the module level.
llvm-svn: 230133
|
| |
|
|
| |
llvm-svn: 230132
|
| |
|
|
|
|
| |
have. Also, the subtarget is invalid at this point.
llvm-svn: 230131
|
| |
|
|
|
|
|
|
| |
Synthesizing a call directly using the MI layer would confuse the frame
lowering code. This is problematic as frame lowering is highly
sensitive the particularities of calls, etc.
llvm-svn: 230129
|
| |
|
|
|
|
| |
This adds section group support to the tools obj2yaml and yaml2obj.
llvm-svn: 230124
|
| |
|
|
|
|
| |
Pointed out by David Majnemer.
llvm-svn: 230122
|
| |
|
|
|
|
|
|
|
|
|
| |
Everyone except R600 was manually passing the length of a static array
at each callsite, calculated in a variety of interesting ways. Far
easier to let ArrayRef handle that.
There should be no functional change, but out of tree targets may have
to tweak their calls as with these examples.
llvm-svn: 230118
|
| |
|
|
|
|
|
|
|
|
| |
Stack realignment occurs after the prolog, not during, for Win64.
Because of this, don't factor in the maximum stack alignment when
establishing a frame pointer.
This fixes PR22572.
llvm-svn: 230113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse (and write) symbolic constants in debug info `flags:` fields.
This prevents a readability (and CHECK-ability) regression with the new
debug info hierarchy.
Old (well, current) assembly, with pretty-printing:
!{!"...\\0016387", ...} ; ... [public] [rvalue reference]
Flags field without this change:
!MDDerivedType(flags: 16387, ...)
Flags field with this change:
!MDDerivedType(flags: DIFlagPublic | DIFlagRValueReference, ...)
As discussed in the review thread, this isn't a final state. Most of
these flags correspond to `DW_AT_` symbolic constants, and we might
eventually want to support arbitrary attributes in some form. However,
as it stands now, some of the flags correspond to other concepts (like
`FlagStaticMember`); until things are refactored this is the simplest
way to move forward without regressing assembly.
llvm-svn: 230111
|
| |
|
|
|
|
|
|
| |
Split debug info 'flags' bitfield over a vector so the current flags can
be iterated over. This API (in combination with r230107) will be used
for assembly support for symbolic constants.
llvm-svn: 230108
|
| |
|
|
|
|
|
|
|
| |
Add `DIDescriptor::getFlag(StringRef)` and
`DIDescriptor::getFlagString(unsigned)`. The latter only converts exact
matches; I'll add separate API for breaking the flags bitfield up into
parts.
llvm-svn: 230107
|
| |
|
|
|
|
| |
This prepares for adding string support.
llvm-svn: 230105
|
| |
|
|
|
|
|
|
| |
Leverage `StringRef` inside keyword comparison macros. There's no
reason to be so low-level here, and I'm about to add another
`startswith()` use, so let's make it easy to read.
llvm-svn: 230100
|