appropriate. Patch per report on llvmdev. No testcase because the
original report didn't come with a testcase, and I can't come up with a case
that actually fails.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77986 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77975 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77968 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77946 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77938 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77919 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77918 91177308-0d34-0410-b5e6-96231b3b80d8
__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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77917 91177308-0d34-0410-b5e6-96231b3b80d8
Allow imp-def and imp-use of anything in the scavenger asserts, just like the machine code verifier.
Allow redefinition of a sub-register of a live register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77904 91177308-0d34-0410-b5e6-96231b3b80d8
