| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
that at least failed reliably.
llvm-svn: 205711
|
| |
|
|
|
|
|
|
|
|
|
| |
into a constant size alloca by inlining.
Ran a run over the testsuite, no results out of the noise, fixes
the testcase in the PR.
PR19115.
llvm-svn: 205710
|
| |
|
|
|
|
|
|
|
| |
cygwin has llvm-dwarfdump problems and isn't paying attention to the
specific xfail there.
s390x isn't matching for an unknown reason.
llvm-svn: 205708
|
| |
|
|
| |
llvm-svn: 205707
|
| |
|
|
| |
llvm-svn: 205706
|
| |
|
|
|
|
| |
Patch by Zinovy Nis.
llvm-svn: 205705
|
| |
|
|
|
|
| |
it's being investigated for those.
llvm-svn: 205704
|
| |
|
|
| |
llvm-svn: 205701
|
| |
|
|
| |
llvm-svn: 205699
|
| |
|
|
| |
llvm-svn: 205697
|
| |
|
|
| |
llvm-svn: 205696
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
the lock was released.
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
|
| |
|
|
|
|
|
|
| |
MemoryBuffer
This is the other half of r205676.
llvm-svn: 205677
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MemoryBuffer
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-enable-no-nans-fp-math
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x86_64-mingw32.
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
|