A computable loop exit count does not imply the presence of an induction
variable. Scalar evolution can return a value for an infinite loop.
Fixes PR15926.
llvm-svn: 181495
for constructors and destructors since the original declaration given
by the AT_specification both won't and can't.
Patch by Yacine Belkadi, I've cleaned up the testcases.
llvm-svn: 181471
- simple one-function case
- function-calling case
- external function calling case
- exception throwing case
- vector case
Note: these tests are somewhat coupled to the current format of debug metadata.
llvm-svn: 181469
- requires existing debug information to be present
- fixes up file name and line number information in metadata
- emits a "<orig_filename>-debug.ll" succinct IR file (without !dbg metadata
or debug intrinsics) that can be read by a debugger
- initialize pass in opt tool to enable the "-debug-ir" flag
- lit tests to follow
llvm-svn: 181467
- made all functions virtual so that subclasses can specialize them
- add printInstructionLine so that subclasses can choose whether or not to
print the newline character (without having to implement printBasicBlock()
- added a second constructor to AssemblyWriter that does not require a
SlotTracker, as required in order to keep the SlotTracker helper class outside
AsmWriter.h and buried in the implementation.
llvm-svn: 181466
- previously formatted_raw_ostream tracked columns, now it tracks lines too
- used by (upcoming) DebugIR pass to know the line number to connect to each IR
instruction
llvm-svn: 181463
This patch extends test/MC/PowerPC/ppc64-fixups.s to not only check for
the correct fixup type in the --show-encoding output, but also runs the
generated object file through llvm-readobj -r and verifies that the
correct ELF relocation records were generated.
llvm-svn: 181453
All R_PPC_... relocs should also be present (using the same number)
under the corresponding R_PPC64_... name. The latter were missing
for a couple of cases, which this patch adds.
This is not a big problem when emitting the reloc, because we can
just use the R_PPC_... define instead. But it is a problem when
*dumping* relocations e.g. using llvm-readobj, because this will
expect only R_PPC64_... values when inspecting a ppc64 ELF file.
llvm-svn: 181451
The patch I committed as revision 167864 introduced a regression that
causes LLVM to no longer generate appropriate relocs for @ha/@l symbol
references (but fail an assertion instead).
This is fixed here by re-enabling support for the VK_PPC_GAS_HA16/
VK_PPC_GAS_LO16 variant kinds (and their Darwin variants) in
PPCELFObjectWriter.cpp.
Tested by running projects/test-suite in -m32 mode with the integrated
assembler forced on. A standalone test case will be committed shortly
as well.
llvm-svn: 181450
The floating-point record forms on PPC don't set the condition register bits
based on a comparison with zero (like the integer record forms do), but rather
based on the exception status bits.
llvm-svn: 181423
The reference encoding is correct, but written in the wrong byte order (these are Thumb tests, while the reference is in ARM byte order).
llvm-svn: 181420
This provides basic functionality for imported declarations. For
subprograms and types some amount of lazy construction is supported (so
the definition of a function can proceed the using declaration), but it
still doesn't handle declared-but-not-defined functions (since we don't
generally emit function declarations).
Variable support is really rudimentary at the moment - simply looking up
the existing definition with no support for out of order (declaration,
imported_module, then definition).
llvm-svn: 181392
The two nested loops were confusing and also conservative in identifying
reduction variables. This patch replaces them by a worklist based approach.
llvm-svn: 181369
DIBuilder::createImportedDeclaration isn't fully plumbed through (note,
lacking in AsmPrinter/DwarfDebug support) but this seemed like a
sufficiently useful division of code to make the subsequent patch(es)
easier to follow.
llvm-svn: 181364
The idea is that docs/ReleaseNotes.rst is 3.3 and will be copied to the
branch by the release manager just before creating the release
candidates.
This ReleaseNotes_34.rst will then be moved over ReleaseNotes.rst after
the 3.3 release.
llvm-svn: 181349
Apparently we didn't keep an association of Compile Unit metadata nodes
to DIEs so looking up that parental context failed & thus caused no
DW_TAG_imported_modules to be emitted at the CU scope. Fix this by
adding the mapping & sure up the test case to verify this.
llvm-svn: 181339
