The register scavenger maintains a DistanceMap that maps MI pointers to their
distance from the top of the current MBB. The DistanceMap is built
incrementally in forward() and in bulk in findFirstUse(). It is used by
scavengeRegister() to determine which candidate register has the longest
unused interval.
Unfortunately the DistanceMap contents can become outdated. The first time
scavengeRegister() is called, the DistanceMap is filled to cover the MBB. If
then instructions are inserted in the MBB (as they always are following
scavengeRegister()), the recorded distances are too short. This causes bad
behaviour in the included test case where a register use /after/ the current
position is ignored because findFirstUse() thinks is is /before/ the current
position. A "using an undefined register" assertion follows promptly.
The fix is to build a fresh DistanceMap at the top of scavengeRegister(), and
discard it after use. This means that DistanceMap is no longer needed as a
RegScavenger member variable, and forward() doesn't need to update it.
The fix then discloses issue number two in the same test case: The candidate
search in scavengeRegister() finds a CSR that has been saved in the prologue,
but is currently unused. It would be both inefficient and wrong to spill such
a register in the emergency spill slot. In the present case, the emergency
slot restore is placed immediately before the normal epilogue restore, leading
to a "Redefining a live register" assertion.
Fix number two: When scavengerRegister() stumbles upon an unused register that
is overwritten later in the MBB, return that register early. It is important
to verify that the register is defined later in the MBB, otherwise it might be
an unspilled CSR.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78650 91177308-0d34-0410-b5e6-96231b3b80d8
the overloaded vector types allowed floating-point or integer vector elements.
Most of these operations actually depend on the element type, so bitcasting
was not an option.
If you include the vpadd intrinsics that I updated earlier, this gets rid
of 20 intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78646 91177308-0d34-0410-b5e6-96231b3b80d8
and short. Well, it's kinda short. Definitely nasty and brutish.
The front-end generates the register/unregister calls into the SjLj runtime,
call-site indices and landing pad dispatch. The back end fills in the LSDA
with the call-site information provided by the front end. Catch blocks are
not yet implemented.
Built on Darwin and verified no llvm-core "make check" regressions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78625 91177308-0d34-0410-b5e6-96231b3b80d8
This definitely slows down asm output so put it under an -asm-exuberant
flag.
This information is useful when doing static analysis of performance
issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78567 91177308-0d34-0410-b5e6-96231b3b80d8
instead of syntactically as a string. This means that it keeps track of the
segment, section, flags, etc directly and asmprints them in the right format.
This also includes parsing and validation support for llvm-mc and
"attribute(section)", so we should now start getting errors about invalid
section attributes from the compiler instead of the assembler on darwin.
Still todo:
1) Uniquing of darwin mcsections
2) Move all the Darwin stuff out to MCSectionMachO.[cpp|h]
3) there are a few FIXMEs, for example what is the syntax to get the
S_GB_ZEROFILL segment type?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78547 91177308-0d34-0410-b5e6-96231b3b80d8
take the table vectors as separate arguments, instead of the previous
approach where they were combined into one big vector.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78525 91177308-0d34-0410-b5e6-96231b3b80d8
2. Move section switch printing to MCSection virtual method which takes a
TAI. This eliminates textual formatting stuff from TLOF.
3. Eliminate SwitchToSectionDirective, getSectionFlagsAsString, and
TLOFELF::AtIsCommentChar.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78510 91177308-0d34-0410-b5e6-96231b3b80d8
A TAI hook is appropriate in this case because this is just an
asm syntax issue, not a semantic difference. TLOF should model
the semantics of the section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78498 91177308-0d34-0410-b5e6-96231b3b80d8
- Part of optimal static profiling patch sequence by Andreas Neustifter.
- Store edge, block, and function information separately for each functions
(instead of in one giant map).
- Return frequencies as double instead of int, and use a sentinel value for
missing information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78477 91177308-0d34-0410-b5e6-96231b3b80d8
Handle large integers, x86_fp80, ConstantAggregateZero, and two more ConstantExpr:
GetElementPtr and IntToPtr
Set SHF_MERGE bit for mergeable strings
Avoid zero initialized strings to be classified as a bss symbol
Don't allow common symbols to be classified as STB_WEAK
Add a constant to be used as a global value offset in data relocations
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78476 91177308-0d34-0410-b5e6-96231b3b80d8
Now there is no special treatment of instructions that redefine part of a
super-register. Instead, the super-register is marked with <imp-use,kill> and
<imp-def>. For instance, from LowerSubregs on ARM:
subreg: CONVERTING: %Q1<def> = INSERT_SUBREG %Q1<undef>, %D1<kill>, 5
subreg: %D2<def> = FCPYD %D1<kill>, 14, %reg0, %Q1<imp-def>
subreg: CONVERTING: %Q1<def> = INSERT_SUBREG %Q1, %D0<kill>, 6
subreg: %D3<def> = FCPYD %D0<kill>, 14, %reg0, %Q1<imp-use,kill>, %Q1<imp-def>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78466 91177308-0d34-0410-b5e6-96231b3b80d8
Verify that early clobber registers and their aliases are not used.
All changes to RegsAvailable are now done as a transaction so the order of
operands makes no difference.
The included test case is from PR4686. It has behaviour that was dependent on the order of operands.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78465 91177308-0d34-0410-b5e6-96231b3b80d8
as vector shuffles did not work out well. Shuffles that produce double-wide
vectors accurately represent the operation but make it hard to do anything
with the results. I considered splitting them up into 2 shuffles, one to
write each register separately, but there doesn't seem to be a good way to
reunite them for codegen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78437 91177308-0d34-0410-b5e6-96231b3b80d8
driven by TAI to being static, driven by tblgen. This means that a
target doesn't get impacted by this stuff at all if it doesn't opt
into it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78427 91177308-0d34-0410-b5e6-96231b3b80d8
The use case is if you have a wrapper class:
class Base {
void *Ptr;
public:
Base() : Ptr(0) { }
operator bool() const { return Ptr; }
.....
}
and sub-wrappers that have exactly the same size:
class Sub : public Base {
public:
....
static bool classof(const Base*);
}
and in the code you would do:
void f(Base b) {
Sub sub = dyn_cast<Sub>(b);
if (sub) {
....
}
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78424 91177308-0d34-0410-b5e6-96231b3b80d8
http://llvm.org/viewvc/llvm-project?view=rev&revision=78127, I'm changing the
ExecutionEngine's global mappings to hold AssertingVH<const GlobalValue>. That
way, if unregistering a mapping fails to actually unregister it, we'll get an
assert. Running the jit nightly tests didn't uncover any actual instances of
the problem.
This also uncovered the fact that AssertingVH<const X> didn't work, so I fixed
that too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78400 91177308-0d34-0410-b5e6-96231b3b80d8
LoopDependenceAnalysis::getLoops is currently O(N*M) for a loop-nest of
depth N and a compound SCEV of M atomic SCEVs. As both N and M will
typically be very small, this should not be a problem. If it turns out
to be one, rewriting getLoops as SCEVVisitor will reduce complexity to
O(M).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78394 91177308-0d34-0410-b5e6-96231b3b80d8
creation activity into the target-specific subclasses of TLOF.
Before this, globals with explicit sections could be created by
the base class.
1. make getOrCreateSection protected, add a new getExplicitSectionGlobal
pure virtual method to assign sections to globals with a specified
section.
2. eliminate getSpecialCasedSectionGlobals, which is now PIC specific.
3. eliminate the getKindForNamedSection virtual method, which is
now just a static method for ELF.
4. Add implementions of getExplicitSectionGlobal for ELF/PECOFF/Darwin/PIC16.
They are now all detangled and understandable, woo! :)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78319 91177308-0d34-0410-b5e6-96231b3b80d8
- start support for new PEI w/reg alloc, allow running RS from emit{Pro,Epi}logue() target hooks.
- fix minor issue with recursion detection.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78318 91177308-0d34-0410-b5e6-96231b3b80d8
just argv[0]. And remove the code for searching the current
working directory and for searching PATH; the point of FindExecutable
is not to find whatever version of the executable can be found by
searching around, but to find an executable that accompanies the
current executable.
Update the tools to use sys::Program::FindProgramByName when they
want PATH searching.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78240 91177308-0d34-0410-b5e6-96231b3b80d8
a dirty hack and isn't need anymore since the last x86 code emitter patch)
- Add a target-dependent modifier to addend calculation
- Use R_X86_64_32S relocation for X86::reloc_absolute_word_sext
- Use getELFSectionFlags whenever possible
- fix getTextSection to use TLOF and emit the right text section
- Handle global emission for static ctors, dtors and Type::PointerTyID
- Some minor fixes
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78176 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of awkwardly encoding calling-convention information with ISD::CALL,
ISD::FORMAL_ARGUMENTS, ISD::RET, and ISD::ARG_FLAGS nodes, TargetLowering
provides three virtual functions for targets to override:
LowerFormalArguments, LowerCall, and LowerRet, which replace the custom
lowering done on the special nodes. They provide the same information, but
in a more immediately usable format.
This also reworks much of the target-independent tail call logic. The
decision of whether or not to perform a tail call is now cleanly split
between target-independent portions, and the target dependent portion
in IsEligibleForTailCallOptimization.
This also synchronizes all in-tree targets, to help enable future
refactoring and feature work.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78142 91177308-0d34-0410-b5e6-96231b3b80d8
for ELF to work.
2) RIP addressing: Use SIB bytes for absolute relocations where RegBase=0,
IndexReg=0.
3) The JIT can get the real address of cstpools and jmptables during
code emission, fix that for object code emission
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78129 91177308-0d34-0410-b5e6-96231b3b80d8
the masm backend. If anyone cares about masm in the future,
we'll have semantic sections it can hang off of.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78096 91177308-0d34-0410-b5e6-96231b3b80d8
few places in InstCombine to use it, to fix problems handling pointer
types. This fixes the recent llvm-gcc bootstrap error.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78005 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
