Instead of crashing, raise an error when a subtraction expression
involves an undefined symbol.

This fixes PR18375.

llvm-svn: 198590

llvm-svn: 198588

llvm-svn: 198587

The 0x66 prefix toggles between 16-bit and 32-bit addressing mode.
So in 32-bit mode it is used to switch to 16-bit addressing mode for the
following instruction, while in 16-bit mode it's the other way round — it's
used to switch to 32-bit mode instead.

Thus, emit the 0x66 prefix byte for OpSize only in 32-bit (and 64-bit) mode,
and introduce a new OpSize16 bit which is used in 16-bit mode instead.

This is just the basic infrastructure for that change; a subsequent patch
will add the new OpSize16 bit to the 32-bit instructions that need it.

Patch from David Woodhouse.

llvm-svn: 198586

llvm-svn: 198585

This is not really expected to work right yet. Mostly because we will
still emit the OpSize (0x66) prefix in all the wrong places, along with
a number of other corner cases. Those will all be fixed in the subsequent
commits.

Patch from David Woodhouse.

llvm-svn: 198584

There is a wrong assumption that the vector element type and the
type of each ConstantSDNode in the build_vector were the same.
However, when promoting the integer operand of a legally typed
build_vector, the operand type and the vector element type do not
need to be the same
(See method 'DAGTypeLegalizer::PromoteIntOp_BUILD_VECTOR' in
LegalizeIntegerTypes.cpp).

  in AArch64 backend, the following dag sequence:

  C0: i1 = Constant<0>
  C1: i1 = Constant<-1>
  V: v8i1 = BUILD_VECTOR C1, C1, C0, C0, C0, C0, C0, C0

  is type-legalized into:

  NewC0: i32 = Constant<0>
  NewC1: i32 = Constant<1>
  V: v8i8 = BUILD_VECTOR NewC1, NewC1, NewC0, NewC0, NewC0, NewC0, NewC0, NewC0

Forcing a getZeroExtend to VTBits to ensure that the new constant
is correctly.

llvm-svn: 198582

llvm-svn: 198580

This moves the check up into the parent class so that all targets can use it
without having to copy (and keep in sync) the same error message.

llvm-svn: 198579

Move the ARM EHABI unwind opcode definitions from the ARM MCTargetDesc into LLVM
Support.  This enables sharing of the definitions across the ARM target code as
well as llvm-readobj.  This will allow implementation of the unwind decoding in
llvm-readobj.

llvm-svn: 198576

llvm-svn: 198567

Add some tests to validate correct register selection, including a fix
to an existing test which was requiring the *wrong* output.

Patch from David Woodhouse.

llvm-svn: 198566

Remove opcode from MOV32r0 that I accidentally left when I converted it to Pseudo. Remove FIXME as well.

llvm-svn: 198564

Fix indentation, name registers similar to ARM ARM.

No functionality change!

llvm-svn: 198563

AVX-512: changed property name from "neverHasSideEffects=1" to "hasSideEffects=0", added this property to VMOVSS/VMOVSD;
Optimized a truncate pattern.

llvm-svn: 198562

Removed vzeroupper from AVX-512 mode - our optimization gude does not recommend to insert vzeroupper at all.

llvm-svn: 198557

Missed this when adding the skeleton analysis. Caught by a build break
in the next patch I'm working on when trying to use the analysis.

llvm-svn: 198556

llvm-svn: 198551

llvm-svn: 198550

llvm-svn: 198547

Mark x86 _alt instructions as AsmParserOnly so they will be omitted from disassembler without string matches.

llvm-svn: 198545

Use new ForceDisassemble flag on the 2-byte forms of INC/DEC for 32-bit mode and remove disassmbler table emitter hack.

llvm-svn: 198544

Add a new x86 specific instruction flag to force some isCodeGenOnly instructions to go through to the disassembler tables without resorting to string matches. Apply flag to all _REV instructions.

llvm-svn: 198543

llvm-svn: 198533

__builtin_returnaddress requires that the value passed into is be a constant.
However, at -O0 even a constant expression may not be converted to a constant.
Emit an error message intead of crashing.

llvm-svn: 198531

Mark the 64-bit x86 push/pop instructions as In64BitMode. Mark the corresponding 32-bit versions with the same encodings Not64BitMode. Remove hack from tablegen disassembler table emitter. Fix bad test.

llvm-svn: 198530

All other uses of this macro in LLVM/clang have been moved to the function
definition so follow suite (and the usage advice) here too for consistency.

llvm-svn: 198516

Tag x86 move to/from debug/control registers with Not64BitMode/In64BitMode. Remove disassembler hack.

llvm-svn: 198515

This commit was the source of crasher PR18384:

While deleting: label %for.cond127
An asserting value handle still pointed to this value!
UNREACHABLE executed at llvm/lib/IR/Value.cpp:671!

Reverting to get the builders green, feel free to re-land after fixing up.
(Renato has a handy isolated repro if you need it.)

This reverts commit r198478.

llvm-svn: 198503

llvm-svn: 198484

Fixes PR18356.

llvm-svn: 198480

getSCEV for an ashr instruction creates an intermediate zext
expression when it truncates its operand.

The operand is initially inside the loop, so the narrow zext
expression has a non-loop-invariant loop disposition.

LoopSimplify then runs on an outer loop, hoists the ashr operand, and
properly invalidate the SCEVs that are mapped to value.

The SCEV expression for the ashr is now an AddRec with the hoisted
value as the now loop-invariant start value.

The LoopDisposition of this wide value was properly invalidated during
LoopSimplify.

However, if we later get the ashr SCEV again, we again try to create
the intermediate zext expression. We get the same SCEV that we did
earlier, and it is still cached because it was never mapped to a
Value. When we try to create a new AddRec we abort because we're using
the old non-loop-invariant LoopDisposition.

I don't have a solution for this other than to clear LoopDisposition
when LoopSimplify hoists things.

I think the long-term strategy should be to perform LoopSimplify on
all loops before computing SCEV and before running any loop opts on
individual loops. It's possible we may want to rerun LoopSimplify on
individual loops, but it should rarely do anything, so rarely require
invalidating SCEV.

llvm-svn: 198478

Remove JMP64pcrel32 (jmpq ). There are no tests for it. I'm pretty sure it won't be emitted correctly since it was set to NoImm. And I can't prove that gas accepts 'jmpq' with an immediate either. Remove the special case for it from the disassembler table generator.

llvm-svn: 198475

The motivation is to mark dump methods as used in debug builds so that they can
be called from lldb, but to not do so in release builds so that they can be
dead-stripped.

There's lots of potential follow-up work suggested in the thread
"Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?" on cfe-dev,
but everyone seems to agreen on this subset.

Macro name chosen by fair coin toss.

llvm-svn: 198456

Revert "For disassembly when adding a symbolic operand that is a C++ symbol name, also put the human readable name in a comment."

This reverts commit r198441.

This change doesn't build on Windows, and doesn't do the right thing on
Linux and other platforms that don't use a _Z prefix instead of __Z for
C++ names.

It also had no tests, so it wasn't clear how to fix it forward.

llvm-svn: 198445

symbol name, also put the human readable name in a comment.

Also fix a bug in LLVMDisasmInstruction() that was not flushing
the raw_svector_ostream for the disassembled instruction string
before copying it to the output buffer that was causing truncation
of the output.

rdar://10173828

llvm-svn: 198441

Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.

This patch implements a compromise solution where the mangler uses DataLayout.
This way, any tool that already links with Target (llc, clang) gets the exact
behavior as before and new IR files can be mangled without linking with Target.

With this patch the mangler is constructed with just a DataLayout and DataLayout
is extended to include the information the Mangler needs.

llvm-svn: 198438

llvm-svn: 198437

This reverts commit r198398, thus reapplying r198397.

I had accidentally introduced an endianness issue when applying the hash
to the type unit. Using support::ulittle64_t in the reinterpret_cast in
addDwarfTypeUnitType fixes this issue.

Original commit message:

Debug Info: Type Units: Simplify type hashing using IR-provided unique
names.

What's good for LTO metadata size problems ought to be good for non-LTO
debug info size too, so let's rely on the same uniqueness in both cases.
If it's insufficient for non-LTO for whatever reason (since we now won't
be uniquing CU-local types or any C types - but these are likely to not
be the most significant contributors to type bloat) we should consider a
frontend solution that'll help both LTO and non-LTO alike, rather than
using DWARF-level DIE-hashing that only helps non-LTO debug info size.

It's also much simpler this way and benefits C++ even more since we can
deduplicate lexically separate definitions of the same C++ type since
they have the same mangled name.

llvm-svn: 198436

The loop rerolling pass was failing with an assertion failure from a
failed cast on loops like this:

  void foo(int *A, int *B, int m, int n) {
    for (int i = m; i < n; i+=4) {
      A[i+0] = B[i+0] * 4;
      A[i+1] = B[i+1] * 4;
      A[i+2] = B[i+2] * 4;
      A[i+3] = B[i+3] * 4;
    }
  }

The code was casting the SCEV-expanded code for the new
induction variable to a phi-node. When the loop had a non-constant
lower bound, the SCEV expander would end the code expansion with an
add insted of a phi node and the cast would fail.

It looks like the cast to a phi node was only needed to get the
induction variable value coming from the backedge to compute the end
of loop condition. This patch changes the loop reroller to compare
the induction variable to the number of times the backedge is taken
instead of the iteration count of the loop. In other words, we stop
the loop when the current value of the induction variable ==
IterationCount-1. Previously, the comparison was comparing the
induction variable value from the next iteration == IterationCount.

This problem only seems to occur on 32-bit targets. For some reason,
the loop is not rerolled on 64-bit targets.

PR18290

llvm-svn: 198425