llvm-svn: 159300

which many Mips 64 ABIs use than for O64 which many 
if not all other target ABIs use.

Most architectures have the following 64 bit relocation record format:

  typedef struct
  {
    Elf64_Addr   r_offset; /* Address of reference */
    Elf64_Xword  r_info;   /* Symbol index and type of relocation */
  } Elf64_Rel;

  typedef struct
  {
    Elf64_Addr    r_offset;
    Elf64_Xword   r_info;
    Elf64_Sxword  r_addend;
  } Elf64_Rela;

Whereas N64 has the following format:

  typedef struct
  {
    Elf64_Addr    r_offset;/* Address of reference */
    Elf64_Word  r_sym;     /* Symbol index */
    Elf64_Byte  r_ssym;    /* Special symbol */
    Elf64_Byte  r_type3;   /* Relocation type */
    Elf64_Byte  r_type2;   /* Relocation type */
    Elf64_Byte  r_type;    /* Relocation type */
  } Elf64_Rel;

  typedef struct
  {
    Elf64_Addr    r_offset;/* Address of reference */
    Elf64_Word  r_sym;     /* Symbol index */
    Elf64_Byte  r_ssym;    /* Special symbol */
    Elf64_Byte  r_type3;   /* Relocation type */
    Elf64_Byte  r_type2;   /* Relocation type */
    Elf64_Byte  r_type;    /* Relocation type */
    Elf64_Sxword  r_addend;
  } Elf64_Rela;

The structure is the same size, but the r_info data element 
is now 5 separate elements. Besides the content aspects, 
endian byte reordering will be different for the area with 
each element being endianized separately.

I treat this as generic and continue to pass r_type as 
an integer masking and unmasking the byte sized N64 
values for N64 mode. I've implemented this and it causes no 
affect on other current targets.

This passes make check.

Jack

llvm-svn: 159299

Patch by Ivan Llopard!

llvm-svn: 159281

Original commit message:

If a constant or a function has linkonce_odr linkage and unnamed_addr, mark it
hidden. Being linkonce_odr guarantees that it is available in every dso that
needs it. Being a constant/function with unnamed_addr guarantees that the
copies don't have to be merged.

llvm-svn: 159272

requiring a module.  Original patch by Sunay Ismail, simplified by Arnaud
de Grandmaison, then complicated by me (if a triple was specified on the
command line, output help for that triple, not for the default).

llvm-svn: 159268

before the expression root.  Any existing operators that are changed to use one
of them needs to be moved between it and the expression root, and recursively
for the operators using that one.  When I rewrote RewriteExprTree I accidentally
inverted the logic, resulting in the compacting going down from operators to
operands rather than up from operands to the operators using them, oops.  Fix
this, resolving PR12963.

llvm-svn: 159265

llvm-svn: 159259

'check-llvm'.

Don't worry! 'check' still works! =] To rationalize the names of targets
used to run tests, the vague plan is the following:

make check-llvm  # run LLVM reg/unit tests  (currently 'check')
make check-clang # run Clang reg/unit tests (currently 'clang-test')
make check-rt    # run CompilerRT reg/unit tests
make check-asan  # run ASan reg/unit tests (subset of -rt)
make check-tsan  # run TSan reg/unit tests (subset of -rt)
make check-all   # run as much of the above as is available

The last one respects what projects are checked out and built for
a given tree. Personally, I would like to eventually make 'check' be an
alias for 'check-all'. For now however, it is an alias for 'check-llvm',
and thus no behavior has changed.

While this patch and my plan only really apply to CMake, I think it
might be good to similarly rationalize the naming scheme for the Make
builds.

llvm-svn: 159258

llvm-svn: 159257

llvm-svn: 159254

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

    // 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

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

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

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

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

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

llvm-svn: 159207

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

IntegersSubsetMapping: implemented "diff" operation. Operation allows at the same time perform up to three operations:
- LHS exclude RHS
- LHS intersect RHS (LHS successors will keeped)
- RHS exclude LHS
The complexity is N+M, where
  N is size of LHS
  M is size of RHS.

llvm-svn: 159201

IntegersSubsetMapping: removed exclude operation, it will replaced with more universal "diff" operation in next commit.
Changes was separated onto two commits for better readability.

llvm-svn: 159200

llvm-svn: 159199

llvm-svn: 159197

llvm-svn: 159196

The current patch optimizes frequently used shuffle patterns and gives these instruction sequence reduction.
Before:
      vshufps $-35, %xmm1, %xmm0, %xmm2 ## xmm2 = xmm0[1,3],xmm1[1,3]
       vpermilps       $-40, %xmm2, %xmm2 ## xmm2 = xmm2[0,2,1,3]
       vextractf128    $1, %ymm1, %xmm1
       vextractf128    $1, %ymm0, %xmm0
       vshufps $-35, %xmm1, %xmm0, %xmm0 ## xmm0 = xmm0[1,3],xmm1[1,3]
       vpermilps       $-40, %xmm0, %xmm0 ## xmm0 = xmm0[0,2,1,3]
       vinsertf128     $1, %xmm0, %ymm2, %ymm0
After:
      vshufps $13, %ymm0, %ymm1, %ymm1 ## ymm1 = ymm1[1,3],ymm0[0,0],ymm1[5,7],ymm0[4,4]
      vshufps $13, %ymm0, %ymm0, %ymm0 ## ymm0 = ymm0[1,3,0,0,5,7,4,4]
      vunpcklps       %ymm1, %ymm0, %ymm0 ## ymm0 = ymm0[0],ymm1[0],ymm0[1],ymm1[1],ymm0[4],ymm1[4],ymm0[5],ymm1[5]

llvm-svn: 159188

very first (and worst) placement algorithm. These should now more
accurately reflect the reality of the pass.

llvm-svn: 159185

Remove some duplicate instructions that exist only to given different mnemonics for the assembler. Use InstAlias instead.

llvm-svn: 159184

The primary advantage is that loop optimizations will be applied in a
stable order. This helps debugging and unit test creation. It is also
a better overall implementation without pathologically bad performance
on deep functions.

On large functions (llvm-stress --size=200000 | opt -loops)
Before: 0.1263s
After:  0.0225s

On deep functions (after tweaking llvm-stress, thanks Nadav):
Before: 0.2281s
After:  0.0227s

See r158790 for more comments.

The loop tree is now consistently generated in forward order, but loop
passes are applied in reverse order over the program. If we have a
loop optimization that prefers forward order, that can easily be
achieved by adding a different type of LoopPassManager.

llvm-svn: 159183

llvm-svn: 159182

Make sure type is not extended or untyped before create a constant of the type. No test case. Found by inspection.

llvm-svn: 159179

llvm-svn: 159178