- take->release: LLVM has moved to C++11.  MockWrapper became an instance of unique_ptr.

   - method symbol_iterator::increment disappeared recently, in this revision:

     r200442 | rafael | 2014-01-29 20:49:50 -0600 (Wed, 29 Jan 2014) | 9 lines

Simplify the handling of iterators in ObjectFile.

None of the object file formats reported error on iterator increment. In
retrospect, that is not too surprising: no object format stores symbols or
sections in a linked list or other structure that requires chasing pointers.
As a consequence, all error checking can be done on begin() and end().

This reduces the text segment of bin/llvm-readobj in my machine from 521233 to
518526 bytes.

My change mimics the change that the revision made to lib/DebugInfo/DWARFContext.cpp .

    - const_cast: Shut up a warning from gcc.

I ran unittests/ExecutionEngine/JIT/Debug+Asserts/JITTests to make sure it worked.

- Arch

llvm-svn: 205689

It affected callee's stack pop in x86. It is one of devergences between cygwin and mingw since mingw-gcc-4.6.

Added testcases to llvm/test/CodeGen/X86/win32_sret.ll for cygwin.

llvm-svn: 205688

be used for indexing not only section's names.

No functional changes.

llvm-svn: 205687

DebugInfo: Support namespace aliases as DW_TAG_imported_declaration instead of DW_TAG_imported_module

I really should read the spec more often (and test GCC more often too).
I just assumed that namespace aliases would be the same as using
directives, except with a name. But apparently that's not how the DWARF
standards suggests they be implemented. DWARF4 provides an example and
other non-normative text suggesting that namespace aliases be
implemented by named imported declarations intsead of named imported
modules.

So be it.

llvm-svn: 205685

llvm-svn: 205683

Also update a few null pointers in this function to be consistent with
new null pointers being added.

Patch by Robert Matusewicz!

Differential Revision: http://reviews.llvm.org/D3123

llvm-svn: 205682

This adds a warning when linker_private or linker_private_weak is provided and
we handle it in a compatible manner.

Suggested by Chris Lattner!

llvm-svn: 205681

Makes iteration over implicit and explicit machine operands more
explicit (har har). Insipired by code review discussion for r205565.

llvm-svn: 205680

Member functions defined within a class definition are implicitly
'inline' for linkage purposes. Compilers might slightly favor inlining
functions explicitly marked 'inline', but LLVM doesn't make a stylistic
habit of doing this generally.

llvm-svn: 205679

This consolidates the duplicated MachO checks in the directive parsing for
various directives that are unsupported for Mach-O.  The error message change is
unimportant as this restores the behaviour to that prior to the addition of the
new directive handling.  Furthermore, use a more direct check for MachO
targeting rather than an indirect feature check of the assembler.

Also simplify the test execution command to avoid temporary files.  Further more,
perform the check in both object and assembly emission.

Whether all non-applicable directives are handled is another question.  .fnstart
is marked as being unsupported, however, the complementary .fnend is not.  The
additional unwinding directives are also still honoured.  This change does not
change that, though, it would be good to validate and mark them as being
unsupported if they are unsupported for the MachO emission.

llvm-svn: 205678

This is the other half of r205676.

llvm-svn: 205677

This avoids an extra copy during decompression and avoids the use of
MemoryBuffer which is a weirdly esoteric device that includes unrelated
concepts like "file name" (its rather generic name is a bit misleading).

Similar refactoring of zlib::compress coming up.

llvm-svn: 205676

This restores the linker_private and linker_private_weak lexemes to permit
translation of the deprecated lexmes.  The behaviour is identical to the bitcode
handling: linker_private and linker_private_weak are handled as if private had
been specified.  This enables compatibility with IR generated by LLVM 3.4.

Reported on IRC by ki9a!

llvm-svn: 205675

Differential Revision: http://reviews.llvm.org/D3154

llvm-svn: 205674

Differential Revision: http://reviews.llvm.org/D3237

llvm-svn: 205673

llvm-svn: 205672

Fix "error: private field 'TM' is not used [-Werror,-Wunused-private-field]"

llvm-svn: 205660

This provides more realistic costs for the insert/extractelement instructions
(which are load/store pairs), accounts for the cheap unaligned Altivec load
sequence, and for unaligned VSX load/stores.

Bad news:
MultiSource/Applications/sgefa/sgefa - 35% slowdown (this will require more investigation)
SingleSource/Benchmarks/McGill/queens - 20% slowdown (we no longer vectorize this, but it was a constant store that was scalarized)
MultiSource/Benchmarks/FreeBench/pcompress2/pcompress2 - 2% slowdown

Good news:
SingleSource/Benchmarks/Shootout/ary3 - 54% speedup
SingleSource/Benchmarks/Shootout-C++/ary - 40% speedup
MultiSource/Benchmarks/Ptrdist/ks/ks - 35% speedup
MultiSource/Benchmarks/FreeBench/neural/neural - 30% speedup
MultiSource/Benchmarks/TSVC/Symbolics-flt/Symbolics-flt - 20% speedup

Unfortunately, estimating the costs of the stack-based scalarization sequences
is hard, and adjusting these costs is like a game of whac-a-mole :( I'll
revisit this again after we have better codegen for vector extloads and
truncstores and unaligned load/stores.

llvm-svn: 205658

Remove the declaration of an unimplemented function.

llvm-svn: 205657

llvm-svn: 205656

This way, you can check the number of sign bits in the
operands. The depth parameter it already has is pretty useless
without this.

llvm-svn: 205649

llvm-svn: 205648

llvm-svn: 205647

llvm-svn: 205633

This patch adds the Octeon cnMips instructions seqi/snei and v3mulu/vmm0/vmulu.
It is only for the assembler. Test case is included.

Reviewed by: Daniel.Sanders@imgtec.com

llvm-svn: 205631

gcc inline asm supports specifying "cc" as a clobber of all condition
registers. Add just enough modeling of the full register to make this work.
Fixed PR19326.

llvm-svn: 205630

Summary:
They behave in accordance with the Has2008 and ABS2008 configuration bits of the
processor which are used to select between the 1985 and 2008 versions of IEEE
754. In 1985 mode, these instructions are arithmetic (i.e. they raise invalid
operation exceptions when given NaN), in 2008 mode they are non-arithmetic
(i.e. they are copies).

nmadd.[ds], and nmsub.[ds] are still subject to -enable-no-nans-fp-math because
the ISA spec does not explicitly state that they obey Has2008 and ABS2008.

Reviewers: matheusalmeida

Reviewed By: matheusalmeida

Differential Revision: http://llvm-reviews.chandlerc.com/D3274

llvm-svn: 205628

When LLVM sees something like (v1iN (vselect v1i1, v1iN, v1iN)) it can
decide that the result is OK (v1i64 is legal on AArch64, for example)
but it still need scalarising because of that v1i1. There was no code
to do this though.

AArch64 and ARM64 have DAG combines to produce efficient code and
prevent that occuring in *most* such situations, but there are edge
cases that they miss. This adds a legalization to cope with that.

llvm-svn: 205626

There were several overlapping problems here, and this solution is
closely inspired by the one adopted in AArch64 in r201381.

Firstly, scalarisation of v1i1 setcc operations simply fails if the
input types are legal. This is fixed in LegalizeVectorTypes.cpp this
time, and allows AArch64 code to be simplified slightly.

Second, vselect with such a setcc feeding into it ends up in
ScalarizeVectorOperand, where it's not handled. I experimented with an
implementation, but found that whatever DAG came out was rather
horrific. I think Hao's DAG combine approach is a good one for
quality, though there are edge cases it won't catch (to be fixed
separately).

Should fix PR19335.

llvm-svn: 205625

Removed "GNU Assembler extension (compatibility)" definitions from ARMInstrInfo.td
Fixed ARMAsmParser::ParseInstruction GNU compatability branch, so it also works for thumb mode from now.
Added new tests.

llvm-svn: 205622

Sorry for the breakage.

For now, it will fail in two ways:

  1. To fail for targeting x86_64-mingw32.
    <stdin>:131:8: note: possible intended match here
    0x30830a0100000002 3 0 1 0 0 is_stmt

  2. To fail not to find the target x86.
    llc: : error: unable to get target for 'x86_64-unknown-unknown',
      see --version and --triple.

llvm-svn: 205621

The previous patterns directly inserted FMOV or INS instructions into
the DAG for scalar_to_vector & bitconvert patterns. This is horribly
inefficient and can generated lots more GPR <-> FPR register traffic
than necessary.

It's much better to emit instructions the register allocator
understands so it can coalesce the copies when appropriate.

It led to at least one ISelLowering hack to avoid the problems, which
was incorrect for v1i64 (FPR64 has no dsub). It can now be removed
entirely.

This should also fix PR19331.

llvm-svn: 205616

Without this change, the llvm_unreachable kicked in. The code pattern
being spotted is rather non-canonical for 128-bit MLAs, but it can
happen and there's no point in generating sub-optimal code for it just
because it looks odd.

Should fix PR19332.

llvm-svn: 205615

llvm-svn: 205612

llvm-svn: 205610

llvm-svn: 205605

No functional change.

llvm-svn: 205604

llvm-svn: 205603

No functional change.

llvm-svn: 205602

recoloring cut-offs are encountered and register allocation failed.

This is related to PR18747

Patch by MAYUR PANDEY <mayur.p@samsung.com>.

llvm-svn: 205601