| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 100504
|
| |
|
|
|
|
| |
diagnostic handler.
llvm-svn: 100503
|
| |
|
|
|
|
|
| |
Operand 2 on a load instruction does not have to be a RegisterSDNode for this to
work.
llvm-svn: 100497
|
| |
|
|
| |
llvm-svn: 100494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the stream. New demo:
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
$ otool -tv t.o
t.o:
(__TEXT,__text) section
_foo:
0000000000000000 subq $0x08,%rsp
0000000000000004 movl %edi,(%rsp)
0000000000000007 movl %edi,%eax
0000000000000009 incl %eax
000000000000000b movl %eax,(%rsp)
000000000000000e movl %eax,0x04(%rsp)
0000000000000012 addq $0x08,%rsp
0000000000000016 ret
llvm-svn: 100492
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
demo:
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
<inline asm>:1:2: error: unrecognized instruction
abc incl %eax
^
LLVM ERROR: Error parsing inline asm
Only problem seems to be that the parser finalizes OutStreamer
at the end of the first inline asm, which isn't what we want.
For example:
$ cat asm.c
int foo(int X) {
__asm__ ("incl %0" : "+r" (X));
return X;
}
$ clang asm.c -S -o - -emit-llvm | llc
...
subq $8, %rsp
movl %edi, (%rsp)
movl %edi, %eax
## InlineAsm Start
incl %eax
## InlineAsm End
movl %eax, (%rsp)
movl %eax, 4(%rsp)
addq $8, %rsp
ret
$ clang asm.c -S -o - -emit-llvm | llc -filetype=obj -o t.o
$ otool -tv t.o
t.o:
(__TEXT,__text) section
_foo:
0000000000000000 subq $0x08,%rsp
0000000000000004 movl %edi,(%rsp)
0000000000000007 movl %edi,%eax
0000000000000009 incl %eax
$
don't stop at inc!
llvm-svn: 100491
|
| |
|
|
|
|
| |
the FP encoding directly as a hex representation.
llvm-svn: 100487
|
| |
|
|
|
|
| |
a co-committed clang patch.
llvm-svn: 100485
|
| |
|
|
| |
llvm-svn: 100480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
undefs in branches/switches, we have two cases: a branch on a literal
undef or a branch on a symbolic value which is undef. If we have a
literal undef, the code was correct: forcing it to a constant is the
right thing to do.
If we have a branch on a symbolic value that is undef, we should force
the symbolic value to a constant, which then makes the successor block
live. Forcing the condition of the branch to being a constant isn't
safe if later paths become live and the value becomes overdefined. This
is the case that 'forcedconstant' is designed to handle, so just use it.
This fixes rdar://7765019 but there is no good testcase for this, the
one I have is too insane to be useful in the future.
llvm-svn: 100478
|
| |
|
|
| |
llvm-svn: 100468
|
| |
|
|
| |
llvm-svn: 100467
|
| |
|
|
| |
llvm-svn: 100466
|
| |
|
|
| |
llvm-svn: 100461
|
| |
|
|
| |
llvm-svn: 100459
|
| |
|
|
|
|
| |
PR6779
llvm-svn: 100457
|
| |
|
|
| |
llvm-svn: 100455
|
| |
|
|
|
|
|
| |
isn't well specified. ARM really needs to have its instprinter
finished at some point.
llvm-svn: 100439
|
| |
|
|
| |
llvm-svn: 100438
|
| |
|
|
|
|
| |
with spaces in them. Sym->getName() != OS << *Sym
llvm-svn: 100434
|
| |
|
|
| |
llvm-svn: 100423
|
| |
|
|
| |
llvm-svn: 100419
|
| |
|
|
|
|
|
|
|
|
|
| |
instantiating some folding set stuff that GCC isn't, requiring
some types to not be incomplete.
I don't know if clang is right or wrong, but unbreaking the
bot is goodness. Here's the broken build:
http://google1.osuosl.org:8011/builders/clang-x86_64-darwin10-selfhost/builds/1813/steps/compile.llvm.stage2/logs/stdio
llvm-svn: 100418
|
| |
|
|
| |
llvm-svn: 100417
|
| |
|
|
| |
llvm-svn: 100416
|
| |
|
|
| |
llvm-svn: 100415
|
| |
|
|
| |
llvm-svn: 100414
|
| |
|
|
| |
llvm-svn: 100412
|
| |
|
|
| |
llvm-svn: 100410
|
| |
|
|
| |
llvm-svn: 100409
|
| |
|
|
| |
llvm-svn: 100408
|
| |
|
|
| |
llvm-svn: 100407
|
| |
|
|
| |
llvm-svn: 100406
|
| |
|
|
|
|
| |
instead of going through DwarfWriter.
llvm-svn: 100405
|
| |
|
|
| |
llvm-svn: 100404
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
uint32_t insn;
MemoryObject.readBytes(Address, 4, (uint8_t*)&insn, NULL)
to read 4 bytes of memory contents into a 32-bit uint variable. This leaves the
interpretation of byte order up to the host machine and causes PPC test cases of
arm-tests, neon-tests, and thumb-tests to fail. Fixed to use a byte array for
reading the memory contents and shift the bytes into place for the 32-bit uint
variable in the ARM case and 16-bit halfword in the Thumb case.
llvm-svn: 100403
|
| |
|
|
|
|
|
| |
allowing xcore to use the normal runOnMachineFunction
implementation.
llvm-svn: 100402
|
| |
|
|
|
|
| |
need it anymore, so don't addRequire it.
llvm-svn: 100400
|
| |
|
|
| |
llvm-svn: 100399
|
| |
|
|
| |
llvm-svn: 100386
|
| |
|
|
| |
llvm-svn: 100385
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a target instruction wants to set target-specific flags, it should simply
set bits in the TSFlags bit vector defined in the Instruction TableGen class.
This works well because TableGen resolves member references late:
class I : Instruction {
AddrMode AM = AddrModeNone;
let TSFlags{3-0} = AM.Value;
}
let AM = AddrMode4 in
def ADD : I;
TSFlags gets the expected bits from AddrMode4 in this example.
llvm-svn: 100384
|
| |
|
|
| |
llvm-svn: 100382
|
| |
|
|
| |
llvm-svn: 100381
|
| |
|
|
| |
llvm-svn: 100380
|
| |
|
|
| |
llvm-svn: 100379
|
| |
|
|
|
|
| |
buildbots started complaining since this commit. Also xfail ARM disassembly tests.
llvm-svn: 100378
|
| |
|
|
| |
llvm-svn: 100377
|
| |
|
|
| |
llvm-svn: 100376
|
| |
|
|
| |
llvm-svn: 100375
|