llvm-svn: 159243

llvm-svn: 159242

suitable for building as a whole-project.

llvm-svn: 159241

llvm-svn: 159240

llvm-svn: 159239

Don't override a custom diagnostic w/ a generic InvalidOperand, all else
being equal.

llvm-svn: 159238

It's not necessary for each DI class to have its own copy of `print' and
`dump'. Instead, just give DIDescriptor those methods and have it call the
appropriate debugging printing routine based on the type of the debug
information.

llvm-svn: 159237

Add a missing check to avoid dereference null. No sensible test case possible. Sorry. rdar://11745134

llvm-svn: 159236

llvm-svn: 159235

llvm-svn: 159234

llvm-svn: 159233

This is only implemented on linux at the moment.

llvm-svn: 159232

in subclasses.

llvm-svn: 159231

    // C - zext(bool) -> bool ? C - 1 : C
    if (ZExtInst *ZI = dyn_cast<ZExtInst>(Op1))
      if (ZI->getSrcTy()->isIntegerTy(1))
        return SelectInst::Create(ZI->getOperand(0), SubOne(C), C);

This ends up forming sext i1 instructions that codegen to terrible code. e.g.
int blah(_Bool x, _Bool y) {
  return (x - y) + 1;
}
=>
        movzbl  %dil, %eax
        movzbl  %sil, %ecx
        shll    $31, %ecx
        sarl    $31, %ecx
        leal    1(%rax,%rcx), %eax
        ret


Without the rule, llvm now generates:
        movzbl  %sil, %ecx
        movzbl  %dil, %eax
        incl    %eax
        subl    %ecx, %eax
        ret

It also helps with ARM (and pretty much any target that doesn't have a sext i1 :-).

The transformation was done as part of Eli's r75531. He has given the ok to
remove it.

rdar://11748024

llvm-svn: 159230

llvm-svn: 159229

The cpuid registers are only available in privileged mode so we don't have
an OS-independent way of implementing this. ARM doesn't provide a list of
processor IDs so the list is somewhat incomplete.

llvm-svn: 159228

llvm-svn: 159227

as a gcc supported extension with usual treatment
with -pedantic (warn) and -pedantic-errors (error).
// rdar://11550996

llvm-svn: 159226

llvm-svn: 159225

llvm-svn: 159224

llvm-svn: 159223

Support the following intrinsics:
  _mm_mask_i32gather_pd, _mm256_mask_i32gather_pd, _mm_mask_i64gather_pd
  _mm256_mask_i64gather_pd, _mm_mask_i32gather_ps, _mm256_mask_i32gather_ps
  _mm_mask_i64gather_ps, _mm256_mask_i64gather_ps

llvm-svn: 159222

Support the following intrinsics:
llvm.x86.avx2.gather.d.pd, llvm.x86.avx2.gather.q.pd
llvm.x86.avx2.gather.d.pd.256, llvm.x86.avx2.gather.q.pd.256
llvm.x86.avx2.gather.d.ps, llvm.x86.avx2.gather.q.ps
llvm.x86.avx2.gather.d.ps.256, llvm.x86.avx2.gather.q.ps.256

Modified Disassembler to handle VSIB addressing mode.

llvm-svn: 159221

the member expression is qualified, call the method specified in the code,
not the most derived one we can find.

llvm-svn: 159219

llvm-svn: 159218

When generating selection tables for Pat instances, TableGen relied on
an output Instruction's Pattern field being set to infer whether a
chain should be added.

This patch adds additional logic to check various flag fields so that
correct code can be generated even if Pattern is unset.

llvm-svn: 159217

comparison between two templated types when they both appear in a diagnostic.
Type elision will remove indentical template arguments, which can be disabled
with -fno-elide-type.  Cyan highlighting is applied to the differing types.

For more formatting, -fdiagnostic-show-template-tree will output the template
type as an indented text tree, with differences appearing inline. Template
tree works with or without type elision.

llvm-svn: 159216

llvm-svn: 159215

llvm-svn: 159214

// rdar://11741435 pr13184

llvm-svn: 159213

to see if we had an underlying final class or method, but we would then
use the cast type to do the call, resulting in a direct call to the wrong
method.

llvm-svn: 159212

Fixed a bug regarding result_of reported by Sven Behne.  The fix is C++11 only mainly because result_of is a variadic beast and working with variadics is just such a problem in C++03 mode.  This should bring result_of up to full conformance with the C++11 spec.

llvm-svn: 159211

PR13114.

llvm-svn: 159210

Such passes can be used to tweak the register assignments in a
target-dependent way, for example to avoid write-after-write
dependencies.

llvm-svn: 159209

--serialize-diagnostics.
rdar://11734800

llvm-svn: 159208

IntegersSubsetTest: Due to compilation failure with -std=c11, replaced -1UL with NOT_A_NUMBER constant (0xffff).

llvm-svn: 159207

literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable 
or a C++11 field) are prefixed by their mangled variable name. 
The descriminator number added to end of the name starts off 
with blank (for first block) and _<N> (for the N+2-th block).

llvm-svn: 159206

llvm-svn: 159204

up to r158925 were handled as processor specific. Making them 
generic and putting tests for these modifiers in the CodeGen/Generic
directory caused a number of targets to fail. 

This commit addresses that problem by having the targets call 
the generic routine for generic modifiers that they don't currently
have explicit code for.

For now only generic print operands 'c' and 'n' are supported.vi


Affected files:

    test/CodeGen/Generic/asm-large-immediate.ll
    lib/Target/PowerPC/PPCAsmPrinter.cpp
    lib/Target/NVPTX/NVPTXAsmPrinter.cpp
    lib/Target/ARM/ARMAsmPrinter.cpp
    lib/Target/XCore/XCoreAsmPrinter.cpp
    lib/Target/X86/X86AsmPrinter.cpp
    lib/Target/Hexagon/HexagonAsmPrinter.cpp
    lib/Target/CellSPU/SPUAsmPrinter.cpp
    lib/Target/Sparc/SparcAsmPrinter.cpp
    lib/Target/MBlaze/MBlazeAsmPrinter.cpp
    lib/Target/Mips/MipsAsmPrinter.cpp
    
MSP430 isn't represented because it did not even run with
the long existing 'c' modifier and it was not apparent what
needs to be done to get it inline asm ready.

Contributer: Jack Carter
llvm-svn: 159203

merge all zero-sized alloca's into one, fixing c43204g from the Ada ACATS
conformance testsuite.  What happened there was that a variable sized object
was being allocated on the stack, "alloca i8, i32 %size".  It was then being
passed to another function, which tested that the address was not null (raising
an exception if it was) then manipulated %size bytes in it (load and/or store).
The optimizers cleverly managed to deduce that %size was zero (congratulations
to them, as it isn't at all obvious), which made the alloca zero size, causing
the optimizers to replace it with null, which then caused the check mentioned
above to fail, and the exception to be raised, wrongly.  Note that no loads
and stores were actually being done to the alloca (the loop that does them is
executed %size times, i.e. is not executed), only the not-null address check.

llvm-svn: 159202