Just add them to the vector of section headers like the rest of the
section headers.

llvm-svn: 184624

llvm-svn: 184623

The improperly aligned section content in the output was causing
buildbot failures. This should fix them.

Incidentally, this results in a simpler and more robust API for
ContiguousBlobAccumulator.

llvm-svn: 184621

We have no targets on trunk that bundle before regalloc. However, we
have been advertising regalloc as bundle safe for use with out-of-tree
targets. We need to at least contain the parts of the code that are
still unsafe.

llvm-svn: 184620

llvm-svn: 184609

It wouldn't really test anything that doesn't already have a more
targeted test:
`yaml2obj-elf-section-basic.yaml`:
  Already tests that section content is correctly passed though.
`yaml2obj-elf-symbol-basic.yaml` (this file):
  Tests that the st_value and st_size attributes of `main` are set
  correctly.
Between those two tests, disassembling the file doesn't really add
anything, so just remove mention of disassembling the file.

llvm-svn: 184607

This reverts commit r184602. In an upcoming commit, I will just remove
the disassembler part of the test; it was mostly just a "nifty" thing
marking a milestone but it doesn't test anything that isn't tested
elsewhere.

llvm-svn: 184606

A FastISel optimization was causing us to emit no information for such
parameters & when they go missing we end up emitting a different
function type. By avoiding that shortcut we not only get types correct
(very important) but also location information (handy) - even if it's
only live at the start of a function & may be clobbered later.

Reviewed/discussion by Evan Cheng & Dan Gohman.

llvm-svn: 184604

llvm-svn: 184602

llvm-svn: 184599

This was causing buildbot failures when build without X86 support.

Is there a way to conditionalize the test on the X86 target being
present?

llvm-svn: 184597

Thanks to Bill Wendling for pointing this out!

llvm-svn: 184593

that have been run through the 'C' pre-processor.

The implementation of SrcMgr.FindLineNumber() is slow but OK if
it uses its cache when called multiple times with an SMLoc that is
forward of the previous call.

In the case of generating dwarf for assembly source files that have
been run through the 'C' pre-processor we need to calculate the
logical line number based on the last parsed cpp hash file line
comment.  And the current code calls SrcMgr.FindLineNumber()
twice to do this causing its cache not to work and results in very
slow compile times:

% time /Volumes/SandBox/build-llvm/Debug+Asserts/bin/llvm-mc -triple thumbv7-apple-ios -filetype=obj -o /tmp/x.o mscorlib.dll.E -g
672.542u 0.299s 11:13.15 99.9%	0+0k 0+2io 2106pf+0w

So we save the info from the last parsed cpp hash file line comment
to avoid making the second call to SrcMgr.FindLineNumber() most times
and end up with compile times like:

% time /Volumes/SandBox/build-llvm/Debug+Asserts/bin/llvm-mc -triple thumbv7-apple-ios -filetype=obj -o /tmp/x.o mscorlib.dll.E -g
3.404u 0.104s 0:03.80 92.1%	0+0k 0+3io 2105pf+0w

rdar://14156934

llvm-svn: 184592

llvm-svn: 184591

Revert "BlockFrequency: Saturate at 1 instead of 0 when multiplying a frequency with a branch probability."

This reverts commit r184584. Breaks PPC selfhost.

llvm-svn: 184590

[objc-arc-opts] Now that PtrState.RRI is encapsulated in PtrState, make PtrState.RRI private and delete the TODO.

llvm-svn: 184587

[objc-arc-opts] Encapsulated PtrState.RRI.{Calls,ReverseInsertPts} into several methods on PtrState.

llvm-svn: 184586

Zero is used by BlockFrequencyInfo as a special "don't know" value. It also
causes a sink for frequencies as you can't ever get off a zero frequency with
more multiplies.

This recovers a 10% regression on MultiSource/Benchmarks/7zip. A zero frequency
was propagated into an inner loop causing excessive spilling.

PR16402.

llvm-svn: 184584

[objcarcopts] Encapsulated PtrState.RRI.IsTrackingImpreciseRelease() => PtrState.IsTrackingImpreciseRelease().

llvm-svn: 184583

[objcarcopts] Encapsulate PtrState.RRI.CFGHazardAfflicted via methods PtrState.{IsCFGHazardAfflicted,SetCFGHazardAfflicted}.

llvm-svn: 184582

IR for CUDA should use "nvptx[64]-nvidia-cuda", and IR for NV OpenCL should use "nvptx[64]-nvidia-nvcl"

llvm-svn: 184579

llvm-svn: 184576

When (srl (anyextend x), c) is folded into (anyextend (srl x, c)), the
high bits are not cleared. Add 'and' to clear off them.

llvm-svn: 184575

llvm-svn: 184574

llvm-svn: 184573

Live intervals for dead physregs may be created during coalescing. We
need to update these in the event that their instruction goes away.

crash.ll is the unit test that catches it when MI sched is enabled on
X86.

llvm-svn: 184572

I want to add logic to handle more cases.

llvm-svn: 184571

llvm-svn: 184570

llvm-svn: 184569

Always coalesce in forward order to propagate rematerialization.
I'm fixing this option so I can enable it by default soon.

llvm-svn: 184568

llvm-svn: 184567

llvm-svn: 184566

llvm-svn: 184565

llvm-svn: 184564

[PowerPC] Support R_PPC_REL16 family of relocations

The GNU assembler supports (as extension to the ABI) use of PC-relative
relocations in half16 fields, which allows writing code like:

  li 1, base-.

This patch adds support for those relocation types in the assembler.

llvm-svn: 184552

[PowerPC] Support various tls-related modifiers

The current code base only supports the minimum set of tls-related
relocations and @modifiers that are necessary to support compiler-
generated code.  This patch extends this to the full set defined
in the ABI (and supported by the GNU assembler) for the benefit
of the assembler parser.

llvm-svn: 184551

[PowerPC] Support @higher et.al. modifiers

This adds support for the @higher, @highera, @highest, and @highesta
modifers, including some missing relocation types.

llvm-svn: 184550

[PowerPC] Support @toc@h modifier

This adds the relocation type and other necessary infrastructure
to use the @toc@h modifier in the assembler.

llvm-svn: 184549

[PowerPC] Support @h modifier

This adds necessary infrastructure to support the @h modifier.
Note that all required relocation types were already present
(and unused).

This patch provides support for using @h in the assembler;
it would also be possible to now use this feature in code
generated by the compiler, but this is not done yet.

llvm-svn: 184548

[PowerPC] Rename some more VK_PPC_ enums

This renames more VK_PPC_ enums, to make them more closely reflect
the @modifier string they represent.  This also prepares for adding
a bunch of new VK_PPC_ enums in upcoming patches.

For consistency, some MO_ flags related to VK_PPC_ enums are
likewise renamed.

No change in behaviour.

llvm-svn: 184547