Several of the 64-bit fixed-point instructions with immediate operands were
using the 32-bit (i32) operand nodes instead of the corresponding 64-bit (i64)
operand definitions (u16imm instead of u16imm64, for example).

This error has had no effect so far, but would have caused type-checking
violations with an upcoming change.

llvm-svn: 198356

As noted in the comment above CodeGenPrepare::OptimizeInst, which aggressively
sinks compares to reduce pressure on the condition register(s), for targets
such as PowerPC with multiple condition registers, this may not be the right
thing to do. This adds an HasMultipleConditionRegisters boolean to TLI, and
CodeGenPrepare::OptimizeInst is skipped when HasMultipleConditionRegisters is
true.

This functionality will be used by the PowerPC backend in an upcoming commit.
Especially when the PowerPC backend starts tracking individual condition
register bits as separate allocatable entities (which will happen in this
upcoming commit), this sinking from CodeGenPrepare::OptimizeInst is
significantly suboptimial.

llvm-svn: 198354

llvm-svn: 198353

I originally had these using opt -verify, and I never removed the
-verify when converting them to use llvm-as instead, so these were
failing because of using the -verify argument which llvm-as doesn't have
instead of what it's actually supposed to be testing.

llvm-svn: 198352

Use an if statement instead of a pair of ternary operators checking
the same condition.
Use a cheap method call rather than returning the local symbol.

llvm-svn: 198351

llvm-svn: 198350

llvm-svn: 198349

Even within a multiclass, we had been generating concrete implicit anonymous
defs when parsing values (generally in value lists). This behavior was
incorrect, and led to errors when multiclass parameters were used in the
parameter list of the implicit anonymous def.

If we had some multiclass:

multiclass mc<string n> {

 ... : SomeClass<SomeOtherClass<n> >

The capture of the multiclass parameter 'n' would not work correctly, and
depending on how the implicit SomeOtherClass was used, either TableGen would
ignore something it shouldn't, or would crash.

To fix this problem, when inside a multiclass, we generate prototype anonymous
defs for implicit anonymous defs (just as we do for explicit anonymous defs).
Within the multiclass, the current record prototype is populated with a node
that is essentially: !cast<SomeOtherClass>(!strconcat(NAME, anon_value_name)).
This is then resolved to the correct concrete anonymous def, in the usual way,
when NAME is resolved during multiclass instantiation.

llvm-svn: 198348

A ValueType in a pattern dag is a type cast, and GetNumNodeResults should
handle it (the type cast has only one result).

This comes up, for example, during the type checking of pattern fragments, for
example, AArch64's Neon_combine_2d fragment is:
  dag Operands = (ops node:$Rm, node:$Rn);
  dag Fragment = (v2f64 (concat_vectors (v1f64 node:$Rm), (v1f64 node:$Rn)));

llvm-svn: 198347

llvm-svn: 198346

llvm-svn: 198345

Plugins need to go in build/Debug/lib as well (rather than build/lib/Debug).

Also, fix the SHLIBDIR path for Xcode, which by default includes Xcode build
settings rather than a simple %(build_mode)s parameter.

llvm-svn: 198344

for pointing this out.
 

llvm-svn: 198341

TableGen had been generating a different name for an anonymous multiclass's
NAME for every def in the multiclass. This had an unfortunate side effect: it
was impossible to reference one def within the multiclass from another (in the
parameter list, for example). By making sure we only generate an anonymous name
once per multiclass (which, as it turns out, requires only changing the name
parameter to reference type), we can now concatenate NAME within the multiclass
with a def name in order to generate a reference to that def.

This does not matter so much, in and of itself, but is necessary for a
follow-up commit that will fix variable capturing in implicit anonymous
multiclass defs (and that is important).

llvm-svn: 198340

When widening an IV to remove s/zext, we generally try to eliminate
the original narrow IV. However, LCSSA phi nodes outside the loop were
still using the original IV. Clean this up more aggressively to avoid
redundancy in generated code.

llvm-svn: 198338

llvm-svn: 198336

llvm-svn: 198335

Based on a patch by Maciej Piechotka.

llvm-svn: 198334

This reverts r197927 until the discussion on llvm-commits comes to a
conclusion.

llvm-svn: 198333

llvm-svn: 198332

llvm-svn: 198330

Mark PUSHFS64/PUSHGS64/POPFS64/POPGS64 as In64BitMode and remove the hack from the disassembler table builder.

llvm-svn: 198327

llvm-svn: 198325

Mark all x86 Int_ and _Int patterns as isCodeGenOnly so the disassembler table builder doesn't need to string match them to exclude them.

llvm-svn: 198323

When building Clang separately from LLVM with CMake, one should set
the path of llvm-config via the cache variable LLVM_CONFIG.

llvm-svn: 198316

llvm-svn: 198313

This patch makes it possible to select the ABI with -mattr. It will be used to
forward clang's -target-abi option to llvm's CodeGen.

llvm-svn: 198304

llvm-svn: 198292

llvm-svn: 198291

When there are cycles in the value graph we have to be careful interpreting
"Value*" identity as "value" equivalence. We interpret the value of a phi node
as the value of its operands.
When we check for value equivalence now we make sure that the "Value*" dominates
all cycles (phis).

%0 = phi [%noaliasval, %addr2]
%l = load %ptr
%addr1 = gep @a, 0, %l
%addr2 = gep @a, 0, (%l + 1)
store %ptr ...

Before this patch we would return NoAlias for (%0, %addr1) which is wrong
because the value of the load is from different iterations of the loop.

Tested on x86_64 -mavx at O3 and O3 -flto with no performance or compile time
regressions.

PR18068
radar://15653794

llvm-svn: 198290

Suggested by Aaron Ballman.

llvm-svn: 198288

During the years there have been some attempts at figuring out how to
align byval arguments. A look at the commit log suggests that they
were

* Use the ABI alignment.
* When that was not sufficient for x86-64, I added the 's' specification to
  DataLayout.
* When that was not sufficient Evan added the virtual getByValTypeAlignment.
* When even that was not sufficient, we just got the FE to add the alignment
  to the byval.

This patch is just a simple cleanup that removes my first attempt at fixing the
problem. I also added an AArch64 implementation of getByValTypeAlignment to
make sure this patch is a nop. I also left the 's' parsing for backward
compatibility.

I will send a short email to llvmdev about the change for anyone maintaining
an out of tree target.

llvm-svn: 198287

llvm-svn: 198286

Remove modifierType/Base from X86 disassembler tables as they are no longer used. Removes ~11.5K from static tables.

llvm-svn: 198284

llvm-svn: 198281

[SparcV9]: Use SRL instead of SLL to clear top 32-bits in ctpop:i32. SLL does not clear top 32 bit, only SRL does.

llvm-svn: 198280

llvm-svn: 198279

Remove need for MODIFIER_OPCODE in the disassembler tables. AddRegFrms are really more like OrRegFrm so we don't need a difference since we can just mask bits.

llvm-svn: 198278

Printing rounding control.
Enncoding for EVEX_RC (rounding control).

llvm-svn: 198277

Second attempt at Removing special form of AddRegFrm used by FP instructions. These instructions can be handled by MRMXr instead.

llvm-svn: 198276