| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
it is just being used as a prefix, so forward substitute it directly.
llvm-svn: 78067
|
| |
|
|
|
|
| |
section on ELF targets.
llvm-svn: 78066
|
| |
|
|
| |
llvm-svn: 78060
|
| |
|
|
| |
llvm-svn: 78059
|
| |
|
|
|
|
| |
ldm / stm.
llvm-svn: 78057
|
| |
|
|
|
|
|
|
| |
add new concrete versions for 1/2/4-byte mergable strings.
These are not actually created yet.
llvm-svn: 78055
|
| |
|
|
| |
llvm-svn: 78047
|
| |
|
|
| |
llvm-svn: 78043
|
| |
|
|
|
|
| |
faster) generic algorithm for now. If more accurate computation is needed, we'll rely on the disassembler.
llvm-svn: 78032
|
| |
|
|
| |
llvm-svn: 78031
|
| |
|
|
|
|
| |
This is a bit of pre-mature optimization. 8-bit variant makes it likely it will be narrowed to a 16-bit instruction.
llvm-svn: 78030
|
| |
|
|
|
|
| |
results to fixed registers.
llvm-svn: 78025
|
| |
|
|
| |
llvm-svn: 78024
|
| |
|
|
| |
llvm-svn: 78020
|
| |
|
|
| |
llvm-svn: 78014
|
| |
|
|
| |
llvm-svn: 78013
|
| |
|
|
|
|
| |
replicating the logic manually.
llvm-svn: 78011
|
| |
|
|
|
|
| |
textual sections.
llvm-svn: 78007
|
| |
|
|
| |
llvm-svn: 78006
|
| |
|
|
|
|
| |
hey it uses .previous, so it should work :)
llvm-svn: 78004
|
| |
|
|
|
|
| |
more step towards "semantics sections"
llvm-svn: 78002
|
| |
|
|
|
|
| |
Add a testcase.
llvm-svn: 77992
|
| |
|
|
|
|
| |
Thanks Chris.
llvm-svn: 77987
|
| |
|
|
|
|
| |
code that I will be using shortly.
llvm-svn: 77983
|
| |
|
|
| |
llvm-svn: 77978
|
| |
|
|
|
|
|
| |
This will cause it to enter the ".text" section instead of "_text"
but masm is already broken.
llvm-svn: 77977
|
| |
|
|
|
|
|
| |
- The theory is these should never actually be called, since these boil down to
passes which can access the target data via the standard mechanism.
llvm-svn: 77975
|
| |
|
|
|
|
| |
like "LLVM ERROR: llvm: error:" or "LLVM ERROR: ERROR:".
llvm-svn: 77971
|
| |
|
|
|
|
|
|
| |
Since we're generating stubs by hands we don't follow the ABI and don't
create a register spill area.
Don't use this area in compilation callback!
llvm-svn: 77968
|
| |
|
|
| |
llvm-svn: 77966
|
| |
|
|
| |
llvm-svn: 77965
|
| |
|
|
|
|
| |
fixes here and there (mostly __m64).
llvm-svn: 77964
|
| |
|
|
|
|
| |
also fixes a subtle bug, when 6th v1i64 argument passed wrongly.
llvm-svn: 77963
|
| |
|
|
|
|
| |
and provide a different set of call-clobberred registers.
llvm-svn: 77962
|
| |
|
|
| |
llvm-svn: 77956
|
| |
|
|
| |
llvm-svn: 77950
|
| |
|
|
| |
llvm-svn: 77949
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is not just a matter of passing in the target triple from the module;
currently backends are making decisions based on the build and host
architecture. The goal is to migrate to making these decisions based off of the
triple (in conjunction with the feature string). Thus most clients pass in the
target triple, or the host triple if that is empty.
This has one important change in the way behavior of the JIT and llc.
For the JIT, it was previously selecting the Target based on the host
(naturally), but it was setting the target machine features based on the triple
from the module. Now it is setting the target machine features based on the
triple of the host.
For LLC, -march was previously only used to select the target, the target
machine features were initialized from the module's triple (which may have been
empty). Now the target triple is taken from the module, or the host's triple is
used if that is empty. Then the triple is adjusted to match -march.
The take away is that -march for llc is now used in conjunction with the host
triple to initialize the subtarget. If users want more deterministic behavior
from llc, they should use -mtriple, or set the triple in the input module.
llvm-svn: 77946
|
| |
|
|
| |
llvm-svn: 77944
|
| |
|
|
|
|
| |
Thanks to Eli Friedman for noticing it.
llvm-svn: 77942
|
| |
|
|
|
|
| |
Fixes PR4669
llvm-svn: 77940
|
| |
|
|
|
|
| |
all of multisource as well.
llvm-svn: 77939
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
options, which don't appear to be useful. -enable-mips-absolute-call is
completely unused (and unless I'm mistaken, is supposed to have the
same effect that -relocation-model=dynamic-no-pic should have),
and -disable-mips-abicall appears to be effectively a
synonym for -relocation-model=static. Adjust the few users of hasABICall
to checks which seem more appropriate. Update MipsSubtarget,
MipsTargetMachine, and MipselTargetMachine to synchronize with recent
changes.
llvm-svn: 77938
|
| |
|
|
|
|
| |
- Tidy up some headers.
llvm-svn: 77929
|
| |
|
|
|
|
| |
- The C, C++, MSIL, and Mips backends still need the module.
llvm-svn: 77927
|
| |
|
|
| |
llvm-svn: 77920
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
pushes in the function prolog if the function doesn't have any stack space,
i.e. for a prolog like:
0x40011870: push %r15
0x40011872: push %r14
0x40011874: push %rbx
Patch by Zoltan!
llvm-svn: 77919
|
| |
|
|
|
|
|
|
|
|
| |
Module*.
Also, dropped uses of TargetMachine where unnecessary. The only target which
still takes a TargetMachine& is Mips, I would appreciate it if someone would
normalize this to match other targets.
llvm-svn: 77918
|
| |
|
|
|
|
|
|
|
|
| |
__builtin_bfin_ones does the same as ctpop, so it can be implemented in the front-end.
__builtin_bfin_loadbytes loads from an unaligned pointer with the disalignexcpt instruction. It does the same as loading from a pointer with the low bits masked. It is better if the front-end creates a masked load. We can always instruction select the masked to disalignexcpt+load.
We keep csync/ssync/idle. These intrinsics represent instructions that need workarounds for some silicon revisions. We may even want to convert inline assembler to intrinsics to enable the workarounds.
llvm-svn: 77917
|
| |
|
|
| |
llvm-svn: 77903
|