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
support. This isn't immediately interesting, because Legalize
ends up lowering SELECT_CC if the target doesn't support it,
but this simplifies the process.
Also, if the SELECT_CC would be expanded in Legalize, it
can potentially end up with two copies of the condition
expression. By leaving it as SELECT+SETCC, the SELECT can be
expanded into two SELECTs that use a single SETCC.
The two comparisons are usually CSE'd, but depending on
when various expressions get legalized, the comparison
expression could involve calls to library functions, such
that the comparison expression may not be able to be CSE'd.
This will be needed by a future patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77896 91177308-0d34-0410-b5e6-96231b3b80d8
Use of an <undef> register is treated like an <imp-use>. It is not an error to use a dead <undef> register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77890 91177308-0d34-0410-b5e6-96231b3b80d8
the only real caller (GetFunctionSizeInBytes) uses it.
The custom ARM implementation of this is basically reimplementing
an assembler poorly for negligible gain. It should be removed
IMNSHO, but I'll leave that to ARMish folks to decide.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77877 91177308-0d34-0410-b5e6-96231b3b80d8
behavior of the LSDA section instead of on some random target hook that
needs to be kept in synch with other points of truth.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77855 91177308-0d34-0410-b5e6-96231b3b80d8
getLSDASection() to be more specific. This makes it pretty obvious
that the ELF LSDA section is being specified wrong in PIC mode. We're
probably getting a lot of startup-time relocations to a readonly page,
which is expensive and bad.
Someone who cares about ELF C++ should investigate this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77847 91177308-0d34-0410-b5e6-96231b3b80d8
compute it based on what it knows. As part of this, rename getSectionForMergeableConstant
to getSectionForConstant because it works for non-mergable constants also.
The only functionality change from this is that Xcore will start dropping
its jump tables into readonly section instead of data section in -static mode.
This should be fine as the linker resolves the relocations. If this is a
problem, let me know and we'll come up with another solution.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77833 91177308-0d34-0410-b5e6-96231b3b80d8
to:
.quad X
even on a 32-bit system, where X is not 64-bits. There isn't much that
we can do here, so we just print:
.quad ((X) & 4294967295)
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77818 91177308-0d34-0410-b5e6-96231b3b80d8
should have no state that is specific to particular globals in the
section. In this case, it means the removal of the "isWeak" and
"ExplicitSection" bits. MCSection uses the new form of SectionKind.
To handle isWeak, I introduced a new SectionInfo class, which is
SectionKind + isWeak, and it is used by the part of the code generator
that does classification of a specific global.
The ExplicitSection disappears. It is moved onto MCSection as a new
"IsDirective" bit. Since the Name of a section is either a section
or directive, it makes sense to keep this bit in MCSection. Ultimately
the creator of MCSection should canonicalize (e.g.) .text to whatever
the actual section is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77803 91177308-0d34-0410-b5e6-96231b3b80d8
