This test for function-local metadata did strange things, and never
really sent in valid arguments for `llvm.dbg.declare` and
`llvm.dbg.value` intrinsics. Those that might have once been valid have
bitrotted.
Rewrite it to be a targeted test for function-local metadata --
unrelated to debug info, which is tested elsewhere -- and rename it to
better match other metadata-related tests.
(Note: the scope of function-local metadata changed drastically during
the metadata/value split, but I didn't properly clean up this testcase.
Most of the IR in this file, while invalid for debug info intrinsics,
used to provide coverage for various (now illegal) forms of
function-local metadata.)
llvm-svn: 232290
Summary: This is a first step toward getting proper support for aggregate loads and stores.
Test Plan: Added unittests
Reviewers: reames, chandlerc
Reviewed By: chandlerc
Subscribers: majnemer, joker.eph, chandlerc, llvm-commits
Differential Revision: http://reviews.llvm.org/D7780
Patch by Amaury Sechet
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 232284
* Moved autotools configure & build example out of "Getting Started Quickly (A Summary)" and into BuildingLLVMWithAutoTools.
* Removed the annotations that CMake is the recommended process and Autotools is alternate.
* Added brief documentation about build targets under "Getting Started Quickly..."
* Added Overview text to BuildingLLVMWithAutotools
* Fixed up a broken link.
llvm-svn: 232278
This involved threading the type-to-gep through a data structure, since
the code was relying on the pointer type to carry this information. I
imagine there will be a lot of this work across the project... slow
work chasing each use case, but the assertions will help keep me honest.
llvm-svn: 232277
Replumb the `AsmWriter` so that `Metadata::print()` is generally useful.
(Similarly change `Metadata::printAsOperand()`.)
- `SlotTracker` now has a mode where all metadata will be correctly
numbered when initializing a `Module`. Normally, `Metadata` only
referenced from within `Function`s gets numbered when the `Function`
is incorporated.
- `Metadata::print()` and `Metadata::printAsOperand()` (and
`Metadata::dump()`) now take an optional `Module` argument. When
provided, `SlotTracker` is initialized with the new mode, and the
numbering will be complete and consistent for all calls to `print()`.
- `Value::print()` uses the new `SlotTracker` mode when printing
intrinsics with `MDNode` operands, `MetadataAsValue` operands, or the
bodies of functions. Thus, metadata numbering will be consistent
between calls to `Metadata::print()` and `Value::print()`.
- `Metadata::print()` (and `Metadata::dump()`) now print the full
definition of `MDNode`s:
!5 = !{!6, !"abc", !7}
This matches behaviour for `Value::print()`, which includes the name
of instructions.
- Updated call sites in `Verifier` to call `print()` instead of
`printAsOperand()`.
All this, so that `Verifier` can print out useful failure messages that
involve `Metadata` for PR22777.
Note that `Metadata::printAsOperand()` previously took an optional
`bool` and `Module` operand. The former was cargo-culted from
`Value::printAsOperand()` and wasn't doing anything useful. The latter
didn't give consistent results (without the new `SlotTracker` mode).
llvm-svn: 232275
Adding nullptr to all the IRBuilder stuff because it's the first thing
that fails to build when testing without the back-compat functions, so
I'll keep having to re-add these locally for each chunk of migration I
do. Might as well check them in to save me the churn. Eventually I'll
have to migrate these too, but I'm going breadth-first.
llvm-svn: 232270
Given that the stated purpose of `CheckFailed()` is to provide a nice
spot for a breakpoint, it'd be nice not to have to use a regex to break
on it. Recover the ability to simply use `b CheckFailed` by
specializing the message-only version, and by changing the variadic
version to call into the message-only version.
llvm-svn: 232268
There is no need to look into the location expressions to transfer them,
the only modification to apply is to patch their base address to reflect
the linked function address.
llvm-svn: 232267
Specifically, if there are copy-like instructions in the loop header
they are moved into the loop close to their uses. This reduces the live
intervals of the values and can avoid register spills.
This is working towards a fix for http://llvm.org/PR22230.
Review: http://reviews.llvm.org/D7259
Next steps:
- Find a better cost model (which non-copy instructions should be sunk?)
- Make this dependent on register pressure
llvm-svn: 232262
This actually shares most of its implementation with the generation
of the debug_ranges (the absence of 'a' is not a typo) contribution
for the unit's DW_AT_ranges attribute.
llvm-svn: 232246
The ID can eg. de used in MCSymbol names to differentiate the ones
that need to be created for every unit.
The ID is a constructor parameter and not a static class member so
there is no issue with counter updates if we decide to thread that
code.
llvm-svn: 232245
I'm just going to migrate these in a pretty ad-hoc & incremental way -
providing the backwards compatible API for now, then locally removing
it, fixing a few callers, adding it back in and commiting those callers.
Rinse, repeat.
The assertions should ensure that if I get this wrong we'll find out
about it and not just have one giant patch to revert, recommit, revert,
recommit, etc.
llvm-svn: 232240
Also replace an old use of qsort with it. Compiles down to the same thing but
gives us some type safety. Safes a couple of kb on CommandLine.o.
NFC.
llvm-svn: 232236
The linker on that platform may re-order symbols or strip dead symbols, which
will break bit set checks. Avoid this by hiding the symbols from the linker.
llvm-svn: 232235
Next time, when I fix a typo, I'll take the time to reread the whole
comment instead of waiting for the commit email to realize that there
is another one two words later...
llvm-svn: 232234
Nothing fancy, just a straightforward offset to apply to the original
debug_ranges entries to get them in line with the linked addresses.
llvm-svn: 232232
This fixes pr22854.
The core issue on the bug is that there are multiple instructions that
print the same in assembly. In fact, there doesn't seem to be any
syntax for specifying that a constant that fits in 8 bits should use a 32 bit
immediate.
The attached patch changes fast isel to consider i16immSExt8,
i32immSExt8, and i64immSExt8. They were disabled because fastisel didn’t know
to call the predicate back in the day.
llvm-svn: 232223
This happened to be fairly easy to support backwards compatibility based
on the number of operands (old format had an even number, new format has
one more operand so an odd number).
test/Bitcode/old-aliases.ll already appears to test old gep operators
(if I remove the backwards compatibility in the BitcodeReader, this and
another test fail) so I'm not adding extra test coverage here.
llvm-svn: 232216
I don't think we test invalid bitcode records in any detail, so no test
here - just a change for consistency with existing error checks in
surrounding code.
llvm-svn: 232215
This reapplies the patch previously committed at revision 232190. This was
reverted at revision 232196 as it caused test failures in tests that did not
expect operands to be commuted. I have made the tests more resilient to
reassociation in revision 232206.
llvm-svn: 232209
As a follow-up to r232200, add an `-instcombine` to canonicalize scalar
allocations to `i32 1`. Since r232200, `iX 1` (for X != 32) are only
created by RAUWs, so this shouldn't fire too often. Nevertheless, it's
a cheap check and a nice cleanup.
llvm-svn: 232202
Move type promotion of the size of the array allocation to the end of
`simplifyAllocaArraySize()`. This avoids promoting the type of the
array size if it's a `ConstantInt`, since the next -instcombine
iteration will drop it to a scalar allocation anyway. Similarly, this
avoids promoting the type if it's an `UndefValue`, in which case the
alloca gets RAUW'ed.
This is NFC when considered over the lifetime of -instcombine, since
it's just reducing the number of iterations needed to reach fixed point.
llvm-svn: 232201
Write the `alloca` array size explicitly when it's non-canonical.
Previously, if the array size was `iX 1` (where X is not 32), the type
would mutate to `i32` when round-tripping through assembly.
The testcase I added fails in `verify-uselistorder` (as well as
`FileCheck`), since the use-lists for `i32 1` and `i64 1` change.
(Manman Ren came across this when running `verify-uselistorder` on some
non-trivial, optimized code as part of PR5680.)
The type mutation started with r104911, which allowed array sizes to be
something other than an `i32`. Starting with r204945, we
"canonicalized" to `i64` on 64-bit platforms -- and then on every
round-trip through assembly, mutated back to `i32`.
I bundled a fixup for `-instcombine` to avoid r204945 on scalar
allocations. (There wasn't a clean way to sequence this into two
commits, since the assembly change on its own caused testcase churn, and
the `-instcombine` change can't be tested without the assembly changes.)
An obvious alternative fix -- change `AllocaInst::AllocaInst()`,
`AsmWriter` and `LLParser` to treat `intptr_t` as the canonical type for
scalar allocations -- was rejected out of hand, since this required
teaching them each about the data layout.
A follow-up commit will add an `-instcombine` to canonicalize the scalar
allocation array size to `i32 1` rather than leaving `iX 1` alone.
rdar://problem/20075773
llvm-svn: 232200
We only defer loading metadata inside ParseModule when ShouldLazyLoadMetadata
is true and we have not loaded any Metadata block yet.
This commit implements all-or-nothing loading of Metadata. If there is a
request to load any metadata block, we will load all deferred metadata blocks.
We make sure the deferred metadata blocks are loaded before we materialize any
function or a module.
The default value of the added parameter ShouldLazyLoadMetadata for
getLazyBitcodeModule is false, so the default behavior stays the same.
We only set the parameter to true when creating LTOModule in local contexts.
These can only really be used for parsing symbols, so it's unnecessary to ever
load the metadata blocks.
If we are going to enable lazy-loading of Metadata for other usages of
getLazyBitcodeModule, where deferred metadata blocks need to be loaded, we can
expose BitcodeReader::materializeMetadata to Module, similar to
Module::materialize.
rdar://19804575
llvm-svn: 232198
Follow-up commits will change some of the logic here. Splitting into a
separate function simplifies the logic by allowing early returns instead
of deeper nesting.
llvm-svn: 232197
