|  | Commit message (Collapse) | Author | Age | Files | Lines | 
|---|
| | 
| 
| 
| | llvm-svn: 156265 | 
| | 
| 
| 
| 
| 
| | for AsmPrinter.
llvm-svn: 155982 | 
| | 
| 
| 
| 
| 
| 
| 
| | MCInstPrinter.
All implementations used the same code.
llvm-svn: 153866 | 
| | 
| 
| 
| 
| 
| | using the instruction name table from MCInstrInfo. Reduces static data in the InstPrinter implementations.
llvm-svn: 153863 | 
| | 
| 
| 
| 
| 
| | getInstructionName and the static data it contains since the same tables are already in MCInstrInfo.
llvm-svn: 153860 | 
| | 
| 
| 
| 
| 
| | It's slow, bloated and completely redundant with MCRegisterClass::contains.
llvm-svn: 153782 | 
| | 
| 
| 
| | llvm-svn: 153184 | 
| | 
| 
| 
| 
| 
| | SmallVector of int instead of unsigned for shuffle mask in decode functions. Preparation for another change.
llvm-svn: 153079 | 
| | 
| 
| 
| 
| 
| 
| | Used to allow context sensitive printing of super-register or sub-register
references.
llvm-svn: 152043 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | rdar://10873652
As part of this I updated the llvm-mc disassembler C API to always call the
SymbolLookUp call back even if there is no getOpInfo call back.  If there is a
getOpInfo call back that is tried first and then if that gets no information
then the  SymbolLookUp is called.  I also made the code more robust by
memset(3)'ing to zero the LLVMOpInfo1 struct before then setting
SymbolicOp.Value before for the call to getOpInfo.  And also don't use any
values from the  LLVMOpInfo1 struct if getOpInfo returns 0.  And also don't
use any of the ReferenceType or ReferenceName values from SymbolLookUp if it
returns NULL. rdar://10873563 and rdar://10873683
For the X86 target also fixed bugs so the annotations get printed. 
Also fixed a few places in the ARM target that was not producing symbolic
operands for some instructions.  rdar://10878166
llvm-svn: 151267 | 
| | 
| 
| 
| 
| 
| | MSP430, PPC, PTX, Sparc, X86, XCore.
llvm-svn: 150878 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | > This IR code
> %res = call <8 x float> @llvm.x86.avx.cmp.ps.256(<8 x float> %a0, <8 x float> %a1, i8 14)
> fails with assertion:
>
> llc: X86ATTInstPrinter.cpp:62: void llvm::X86ATTInstPrinter::printSSECC(const llvm::MCInst*, unsigned int, llvm::raw_ostream&): Assertion `0 && "Invalid ssecc argument!"' failed.
> 0  llc             0x0000000001355803
> 1  llc             0x0000000001355dc9
> 2  libpthread.so.0 0x00007f79a30575d0
> 3  libc.so.6       0x00007f79a23a1945 gsignal + 53
> 4  libc.so.6       0x00007f79a23a2f21 abort + 385
> 5  libc.so.6       0x00007f79a239a810 __assert_fail + 240
> 6  llc             0x00000000011858d5 llvm::X86ATTInstPrinter::printSSECC(llvm::MCInst const*, unsigned int, llvm::raw_ostream&) + 119
I added the full testing for all possible pseudo-ops of cmp.
I extended X86AsmPrinter.cpp and X86IntelInstPrinter.cpp.
You'l also see lines alignments (unrelated to this fix) in X86IselLowering.cpp from my previous check-in.
llvm-svn: 150068 | 
| | 
| 
| 
| 
| 
| | decoding.
llvm-svn: 149859 | 
| | 
| 
| 
| | llvm-svn: 149809 | 
| | 
| 
| 
| | llvm-svn: 146409 | 
| | 
| 
| 
| 
| 
| | instruction commenting for AVX/AVX2 forms for integer UNPCKs.
llvm-svn: 145924 | 
| | 
| 
| 
| 
| 
| | type for VPERMILPD/PS. Add instruction selection support for VINSERTI128/VEXTRACTI128.
llvm-svn: 145483 | 
| | 
| 
| 
| | llvm-svn: 145420 | 
| | 
| 
| 
| | llvm-svn: 145392 | 
| | 
| 
| 
| 
| 
| | decoding for VSHUFPS/D for 256-bit types. Add pattern matching for memory forms of VPERMILPS/VPERMILPD.
llvm-svn: 145390 | 
| | 
| 
| 
| 
| 
| | add AVX flavors of many instructions and fix the destination operand for some of the existing AVX entries.
llvm-svn: 145063 | 
| | 
| 
| 
| 
| 
| | correctly. Add support for decoding UNPCKHPS/UNPCKHPD for AVX 128-bit and 256-bit forms.
llvm-svn: 145055 | 
| | 
| 
| 
| | llvm-svn: 143799 | 
| | 
| 
| 
| | llvm-svn: 143634 | 
| | 
| 
| 
| 
| 
| | that the disassembler outputs annotations on with the streamer that the InstPrinter will print them on.
llvm-svn: 140217 | 
| | 
| 
| 
| 
| 
| | return, and the printer accept, an annotation string which can be passed through if the client cares about annotations.
llvm-svn: 139876 | 
| | 
| 
| 
| 
| 
| | MC-based InstPrinters to print them out.  Enhance the ARM and X86 InstPrinter's to do so in verbose mode.
llvm-svn: 139820 | 
| | 
| 
| 
| 
| 
| | case those instructions that the immediate is not sign-extend.  radr://8795217
llvm-svn: 139028 | 
| | 
| 
| 
| | llvm-svn: 138545 | 
| | 
| 
| 
| 
| 
| 
| 
| | vectors. It operates on 128-bit elements instead of regular scalar
types. Recognize shuffles that are suitable for VPERM2F128 and teach
the x86 legalizer how to handle them.
llvm-svn: 137519 | 
| | 
| 
| 
| 
| 
| | the PVS-studio tool.
llvm-svn: 136878 | 
| | 
| 
| 
| | llvm-svn: 136452 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | specified in the same file that the library itself is created. This is
more idiomatic for CMake builds, and also allows us to correctly specify
dependencies that are missed due to bugs in the GenLibDeps perl script,
or change from compiler to compiler. On Linux, this returns CMake to
a place where it can relably rebuild several targets of LLVM.
I have tried not to change the dependencies from the ones in the current
auto-generated file. The only places I've really diverged are in places
where I was seeing link failures, and added a dependency. The goal of
this patch is not to start changing the dependencies, merely to move
them into the correct location, and an explicit form that we can control
and change when necessary.
This also removes a serialization point in the build because we don't
have to scan all the libraries before we begin building various tools.
We no longer have a step of the build that regenerates a file inside the
source tree. A few other associated cleanups fall out of this.
This isn't really finished yet though. After talking to dgregor he urged
switching to a single CMake macro to construct libraries with both
sources and dependencies in the arguments. Migrating from the two macros
to that style will be a follow-up patch.
Also, llvm-config is still generated with GenLibDeps.pl, which means it
still has slightly buggy dependencies. The internal CMake
'llvm-config-like' macro uses the correct explicitly specified
dependencies however. A future patch will switch llvm-config generation
(when using CMake) to be based on these deps as well.
This may well break Windows. I'm getting a machine set up now to dig
into any failures there. If anyone can chime in with problems they see
or ideas of how to solve them for Windows, much appreciated.
llvm-svn: 136433 | 
| | 
| 
| 
| 
| 
| | MCTargetAsmLexer; rename createAsmLexer to createMCAsmLexer and createAsmParser to createMCAsmParser.
llvm-svn: 136027 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | The first problem to fix is to stop creating synthetic *Table_gen
targets next to all of the LLVM libraries. These had no real effect as
CMake specifies that add_custom_command(OUTPUT ...) directives (what the
'tablegen(...)' stuff expands to) are implicitly added as dependencies
to all the rules in that CMakeLists.txt.
These synthetic rules started to cause problems as we started more and
more heavily using tablegen files from *subdirectories* of the one where
they were generated. Within those directories, the set of tablegen
outputs was still available and so these synthetic rules added them as
dependencies of those subdirectories. However, they were no longer
properly associated with the custom command to generate them. Most of
the time this "just worked" because something would get to the parent
directory first, and run tablegen there. Once run, the files existed and
the build proceeded happily. However, as more and more subdirectories
have started using this, the probability of this failing to happen has
increased. Recently with the MC refactorings, it became quite common for
me when touching a large enough number of targets.
To add insult to injury, several of the backends *tried* to fix this by
adding explicit dependencies back to the parent directory's tablegen
rules, but those dependencies didn't work as expected -- they weren't
forming a linear chain, they were adding another thread in the race.
This patch removes these synthetic rules completely, and adds a much
simpler function to declare explicitly that a collection of tablegen'ed
files are referenced by other libraries. From that, we can add explicit
dependencies from the smaller libraries (such as every architectures
Desc library) on this and correctly form a linear sequence. All of the
backends are updated to use it, sometimes replacing the existing attempt
at adding a dependency, sometimes adding a previously missing dependency
edge.
Please let me know if this causes any problems, but it fixes a rather
persistent and problematic source of build flakiness on our end.
llvm-svn: 136023 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | instruction introduced in AVX, which can operate on 128 and 256-bit vectors.
It considers a 256-bit vector as two independent 128-bit lanes. It can permute
any 32 or 64 elements inside a lane, and restricts the second lane to
have the same permutation of the first one. With the improved splat support
introduced early today, adding codegen for this instruction enable more
efficient 256-bit code:
Instead of:
  vextractf128  $0, %ymm0, %xmm0
  punpcklbw %xmm0, %xmm0
  punpckhbw %xmm0, %xmm0
  vinsertf128 $0, %xmm0, %ymm0, %ymm1
  vinsertf128 $1, %xmm0, %ymm1, %ymm0
  vextractf128  $1, %ymm0, %xmm1
  shufps  $1, %xmm1, %xmm1
  movss %xmm1, 28(%rsp)
  movss %xmm1, 24(%rsp)
  movss %xmm1, 20(%rsp)
  movss %xmm1, 16(%rsp)
  vextractf128  $0, %ymm0, %xmm0
  shufps  $1, %xmm0, %xmm0
  movss %xmm0, 12(%rsp)
  movss %xmm0, 8(%rsp)
  movss %xmm0, 4(%rsp)
  movss %xmm0, (%rsp)
  vmovaps (%rsp), %ymm0
We get:
  vextractf128  $0, %ymm0, %xmm0
  punpcklbw %xmm0, %xmm0
  punpckhbw %xmm0, %xmm0
  vinsertf128 $0, %xmm0, %ymm0, %ymm1
  vinsertf128 $1, %xmm0, %ymm1, %ymm0
  vpermilps $85, %ymm0, %ymm0
llvm-svn: 135662 | 
| | 
| 
| 
| | llvm-svn: 134546 | 
| | 
| 
| 
| | llvm-svn: 134525 | 
| | 
| 
| 
| | llvm-svn: 134457 | 
| | 
| 
| 
| | llvm-svn: 134024 | 
| | 
| 
| 
| 
| 
| | into XXXGenRegisterInfo.inc.
llvm-svn: 133922 | 
| | 
| 
| 
| | llvm-svn: 132451 | 
| | 
| 
| 
| 
| 
| 
| 
| | directives.
Fixes PR9826.
llvm-svn: 132317 | 
| | 
| 
| 
| 
| 
| | true on success and false on failure. Update callers.
llvm-svn: 129722 | 
| | 
| 
| 
| 
| 
| | cases, it's much nicer and more informative reading the alias.
llvm-svn: 129497 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | with the newer, cleaner model. It uses the IAPrinter class to hold the
information that is needed to match an instruction with its alias. This also
takes into account the available features of the platform.
There is one bit of ugliness. The way the logic determines if a pattern is
unique is O(N**2), which is gross. But in reality, the number of items it's
checking against isn't large. So while it's N**2, it shouldn't be a massive time
sink.
llvm-svn: 129110 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| | the alias of an InstAlias instead of the thing being aliased. Because we need to
know the features that are valid for an InstAlias.
This is part of a work-in-progress.
llvm-svn: 127986 | 
| | 
| 
| 
| 
| 
| 
| 
| | and 256-bit forms.  Because the number of elements in a vector
      does not determine the vector type (4 elements could be v4f32 or
      v4f64), pass the full type of the vector to decode routines.
llvm-svn: 126664 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | (LLVMX86Utils.a) to break cyclic library dependencies between
LLVMX86CodeGen.a and LLVMX86AsmParser.a.  Previously this code was in
a header file and marked static but AVX requires some additional
functionality here that won't be used by all clients.  Since including
unused static functions causes a gcc compiler warning, keeping it as a
header would break builds that use -Werror.  Putting this in its own
library solves both problems at once.
llvm-svn: 125765 | 
| | 
| 
| 
| | llvm-svn: 123670 |