our current machine instruction defines a register with the same register class
as what's being replaced. This showed up in the SPEC 403.gcc benchmark, where it
would ICE because a tail call was expecting one register class but was given
another. (The machine instruction verifier catches this situation.)
<rdar://problem/10270968>

llvm-svn: 141830

Use a utility from MathExtras to clarify a check and avoid undefined behavior.  Based on patch by Ahmed Charles.

llvm-svn: 141829

The VMAs stored in the symbol table of a MachO file are absolute addresses, not offsets from the section.

llvm-svn: 141828

llvm-svn: 141824

sectionContainsSymbol needs to be based on VMA's rather than section indices to properly account for files with segment load commands that contain no sections.

llvm-svn: 141822

Fix a couple hash functions so that they do not depend on undefined shifts.  Based on patch by Ahmed Charles.

llvm-svn: 141820

The disassembler needs to use the AM5 factory methods instead of just
building up the immediate directly.

llvm-svn: 141819

Fix APFloat::getSmallestNormalized so the shift doesn't depend on undefined behavior.  Patch from Ahmed Charles.

llvm-svn: 141818

Fix APFloat::getLargest so that it actually returns the correct value.  Found by accident while reviewing a patch to nearby code.

llvm-svn: 141816

llvm-svn: 141815

for cpp pre-processed assembly we give correct filename and line numbers when
reporting errors in assembly files when using clang and -integrated-as on .s
files. rdar://8998895

llvm-svn: 141814

Disable machine LICM speculation check (for profitability) until I have time to investigate the regressions.

llvm-svn: 141813

rather than the previous index. If a block has a single instruction, the
previous index may be in a different basic block.

I have no clue how this used to work on all of test-suite, because now this
failure is seen quite often when trying to compile code with -strong-phi-elim.
This fixes PR10252.

llvm-svn: 141812

llvm-svn: 141811

llvm-svn: 141807

llvm-svn: 141794

llvm-svn: 141786

llvm-svn: 141781

llvm-svn: 141780

intended, but only by accident.

llvm-svn: 141779

lib/Object/ELFObjectFile.cpp: Fix undefined behavior for MC/ELF/many-section.s not to fail (on msvc).

DenseMap::lookup(k) would return "default constructor value" when k was not met. It would be useless when value type were POD.

llvm-svn: 141774

containing loop's header to see if that's a landing pad. If it is, then we don't
want to hoist instructions out of the loop and above the header.

llvm-svn: 141767

llvm-svn: 141763

llvm-svn: 141761

Remove unused classes.

llvm-svn: 141757

llvm-svn: 141750

llvm-svn: 141749

1. The speculation check may not have been performed if the BB hasn't had a load
   LICM candidate.
2. If the candidate would be CSE'ed, then go ahead and speculatively LICM the
   instruction even if it's in high register pressure situation.

llvm-svn: 141747

When widening a copy, we are reading a larger register that may not be
live.  Use an <undef> flag to tell the register scavenger and machine
code verifier that we know the value isn't defined.

We now widen:

  %S6<def> = COPY %S4<kill>, %D3<imp-def>

into:

  %D3<def> = VMOVD %D2<undef>, pred:14, pred:%noreg, %S4<imp-use,kill>

This also keeps the <kill> flag on %S4 so we don't inadvertently kill a
live value in %S5.

Finally, ensure that ARMBaseInstrInfo::setExecutionDomain() preserves
the <undef> flag when converting VMOVD to VORR.

llvm-svn: 141746

Also teach MachineLICM to avoid "speculation" when register pressure is high.

llvm-svn: 141744

llvm-svn: 141743

instructions with two register operands derive from it.

llvm-svn: 141742

llvm-svn: 141737

arithmetic and logical instructions with three register operands derive from
them. Fix instruction encoding too.

llvm-svn: 141736

file. Since it should only be used when necessary propagate it through
the backend code generation and tweak testcases accordingly.

This helps with code like in clang's test/CodeGen/debug-info-line.c where
we have multiple #line directives within a single lexical block and want
to generate only a single block that contains each file change.

Part of rdar://10246360

llvm-svn: 141729

llvm-svn: 141728

llvm-svn: 141727

The blocks with invokes have branches to the dispatch block, because that more
correctly models the behavior of the CFG. The dispatch of course has edges to
the landing pads. Those landing pads could contain invokes, which then have
branches back to the dispatch. This creates a loop. The machine LICM pass looks
at this loop and thinks it can hoist elements out of it. But because the
dispatch is an alternate entry point into the program, the hoisted instructions
won't be executed.

I wasn't able to get a testcase which was small and could reproduce all of the
time. The function_try_block.cpp in llvm-test was where this showed up.

llvm-svn: 141726

llvm-svn: 141722

Fill out the rest of the encoding information, update to properly mark
the LDC/STC instructions as predicable while the LDC2/STC2 instructions are
not, and adjust the parser accordingly.

llvm-svn: 141721