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.
llvm-svn: 78650
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.
llvm-svn: 78625
MERGE_VALUES nodes. Replacing the result values with the
operands in one MERGE_VALUES node may cause another
MERGE_VALUES node be CSE'd with the first one, and bring
its uses along, so that the first one isn't dead, as this
code expects. Fix this by iterating until the node is
really dead. This fixes PR4699.
llvm-svn: 78619
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.
llvm-svn: 78567
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.
llvm-svn: 78510
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.
llvm-svn: 78498
Blackfin supports and/or/xor on i32 but not on i16. Teach
DAGCombiner::SimplifyBinOpWithSameOpcodeHands to not produce illegal nodes
after legalize ops.
llvm-svn: 78497
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
llvm-svn: 78476
Also don't dereference old pointers after they have been deleted causing
random crashes when enabling the machine code verifier.
Ahem...
I have not included a test case for the crash. It hapened when enabling the
verifier on CodeGen/X86/2009-08-06-branchfolder-crash.ll.
The crash depends on an MBB being allocated at the same address as a
previously deleted MBB. I don't think that can be reproduced reliably.
llvm-svn: 78472
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>
llvm-svn: 78466
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.
llvm-svn: 78465
- start support for new PEI w/reg alloc, allow running RS from emit{Pro,Epi}logue() target hooks.
- fix minor issue with recursion detection.
llvm-svn: 78318
and high-bits values in ways that weren't correct for integer
types wider than 64 bits. This fixes a miscompile in
PPMacroExpansion.cpp in clang on x86-64.
llvm-svn: 78295
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
llvm-svn: 78176
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.
llvm-svn: 78142
When LowerExtract eliminates an EXTRACT_SUBREG with a kill flag, it moves the
kill flag to the place where the sub-register is killed. This can accidentally
overlap with the use of a sibling sub-register, and we have trouble.
In the test case we have this code:
Live Ins: %R0 %R1 %R2
%R2L<def> = EXTRACT_SUBREG %R2<kill>, 1
%R2H<def> = LOAD16fi <fi#-1>, 0, Mem:LD(2,4) [FixedStack-1 + 0]
%R1L<def> = EXTRACT_SUBREG %R1<kill>, 1
%R0L<def> = EXTRACT_SUBREG %R0<kill>, 1
%R0H<def> = ADD16 %R2H<kill>, %R2L<kill>, %AZ<imp-def>, %AN<imp-def>, %AC0<imp-def>, %V<imp-def>, %VS<imp-def>
subreg: CONVERTING: %R2L<def> = EXTRACT_SUBREG %R2<kill>, 1
subreg: eliminated!
subreg: killed here: %R0H<def> = ADD16 %R2H, %R2L, %R2<imp-use,kill>, %AZ<imp-def>, %AN<imp-def>, %AC0<imp-def>, %V<imp-def>, %VS<imp-def>
The kill flag on %R2 is moved to the last instruction, and the live range overlaps with the definition of %R2H:
*** Bad machine code: Redefining a live physical register ***
- function: f
- basic block: 0x18358c0 (#0)
- instruction: %R2H<def> = LOAD16fi <fi#-1>, 0, Mem:LD(2,4) [FixedStack-1 + 0]
Register R2H was defined but already live.
The fix is to replace EXTRACT_SUBREG with IMPLICIT_DEF instead of eliminating
it completely:
subreg: CONVERTING: %R2L<def> = EXTRACT_SUBREG %R2<kill>, 1
subreg: replace by: %R2L<def> = IMPLICIT_DEF %R2<kill>
Note that these IMPLICIT_DEF instructions survive to the asm output. It is
necessary to fix the stack-color-with-reg test case because of that.
llvm-svn: 78093
Implicit operands no longer get a free pass: Imp-use requires a live register
and imp-def requires a dead register.
There is also no special rule allowing redefinition of a sub-register when the
super-register is live. The super register must have imp-kill+imp-def operands
instead.
llvm-svn: 78090
killed by another operand.
There is probably a better fix. Either 1) scavenger can look at other operands, or
2) livevariables can be smarter about kill markers. Patches welcome.
llvm-svn: 78072
TLI.computeMaskedBitsForTargetNode from ComputeMaskedBits, since
the former may call back into the latter. This fixes a major
compile time problem on a testcase that happnened to hit this
in a particularly bad way, PR4643.
llvm-svn: 78023
When LowerSubregsInstructionPass::LowerInsert eliminates an INSERT_SUBREG
instriction because it is an identity copy, make sure that the same registers
are alive before and after the elimination.
When the super-register is marked <undef> this requires inserting an
IMPLICIT_DEF instruction to make sure the super register is live.
Fix a related bug where a kill flag on the inserted sub-register was not transferred properly.
Finally, clear the undef flag in MachineInstr::addRegisterKilled. Undef implies dead and kill implies live, so they cant both be valid.
llvm-svn: 77989
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.
llvm-svn: 77904
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.
llvm-svn: 77896
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.
llvm-svn: 77847
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.
llvm-svn: 77833
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.
llvm-svn: 77818
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.
llvm-svn: 77803
in SelectionDAGLowering::visitTargetIntrinsic.
This removes a bit of special-case code for vector types. After staring
at it for a while, I managed to convince myself that it is not necessary.
The only case where TLI.getValueType() differs from MVT::getMVT is for iPTR,
so this code could potentially make a difference for a vector of pointers.
But, it looks like that is not supported. Calling TLI.getValueType() on
a vector of pointers leads to the following sequence of calls:
TargetLowering::getValueType
MVT::getMVT
MVT::getVectorVT(iPTR, num elements)
MVT::getExtendedVectorVT
MVT::getTypeForMVT for iPTR
assertion fails "Type is not extended!"
So, unless I'm really missing something, this bit of code is irrelevant to
the current version of LLVM, which is consistent with the fact that I don't
see this code in other similar places.
llvm-svn: 77747
padding is disabled, tabs get replaced by spaces except in the case of
the first operand, where the tab is output to line up the operands after
the mnemonics.
Add some better comments and eliminate redundant code.
Fix some testcases to not assume tabs.
llvm-svn: 77740
thing is #if0'd out anyway. Just simplify the code by reducing the interface.
Not deleting this is essential for Bill's continuing happiness.
llvm-svn: 77736
shouldn't do AU.setPreservesCFG(), because even though CodeGen passes
don't modify the LLVM IR CFG, they may modify the MachineFunction CFG,
and passes like MachineLoop are registered with isCFGOnly set to true.
llvm-svn: 77691
failures when building assorted projects with clang.
--- Reverse-merging r77654 into '.':
U include/llvm/CodeGen/Passes.h
U include/llvm/CodeGen/MachineFunctionPass.h
U include/llvm/CodeGen/MachineFunction.h
U include/llvm/CodeGen/LazyLiveness.h
U include/llvm/CodeGen/SelectionDAGISel.h
D include/llvm/CodeGen/MachineFunctionAnalysis.h
U include/llvm/Function.h
U lib/Target/CellSPU/SPUISelDAGToDAG.cpp
U lib/Target/PowerPC/PPCISelDAGToDAG.cpp
U lib/CodeGen/LLVMTargetMachine.cpp
U lib/CodeGen/MachineVerifier.cpp
U lib/CodeGen/MachineFunction.cpp
U lib/CodeGen/PrologEpilogInserter.cpp
U lib/CodeGen/MachineLoopInfo.cpp
U lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
D lib/CodeGen/MachineFunctionAnalysis.cpp
D lib/CodeGen/MachineFunctionPass.cpp
U lib/CodeGen/LiveVariables.cpp
llvm-svn: 77661
When the return value is not used (i.e. only care about the value in the memory), x86 does not have to use add to implement these. Instead, it can use add, sub, inc, dec instructions with the "lock" prefix.
This is currently implemented using a bit of instruction selection trick. The issue is the target independent pattern produces one output and a chain and we want to map it into one that just output a chain. The current trick is to select it into a merge_values with the first definition being an implicit_def. The proper solution is to add new ISD opcodes for the no-output variant. DAG combiner can then transform the node before it gets to target node selection.
Problem #2 is we are adding a whole bunch of x86 atomic instructions when in fact these instructions are identical to the non-lock versions. We need a way to add target specific information to target nodes and have this information carried over to machine instructions. Asm printer (or JIT) can use this information to add the "lock" prefix.
llvm-svn: 77582
and convert code to using it, instead of having lots of things
poke the isLookupPtrRegClass() method directly.
2. Make PointerLikeRegClass contain a 'kind' int, and store it in
the existing regclass field of TargetOperandInfo when the
isLookupPtrRegClass() predicate is set. Make getRegClass pass
this into TargetRegisterInfo::getPointerRegClass(), allowing
targets to have multiple ptr_rc things.
llvm-svn: 77504
it is highly specific to the object file that will be generated in the end,
this introduces a new TargetLoweringObjectFile interface that is implemented
for each of ELF/MachO/COFF/Alpha/PIC16 and XCore.
Though still is still a brutal and ugly refactoring, this is a major step
towards goodness.
This patch also:
1. fixes a bunch of dangling pointer problems in the PIC16 backend.
2. disables the TargetLowering copy ctor which PIC16 was accidentally using.
3. gets us closer to xcore having its own crazy target section flags and
pic16 not having to shadow sections with its own objects.
4. fixes wierdness where ELF targets would set CStringSection but not
CStringSection_. Factor the code better.
5. fixes some bugs in string lowering on ELF targets.
llvm-svn: 77294
1. Spell SectionFlags::Writeable as "Writable".
2. Add predicates for deriving SectionFlags from SectionKinds.
3. Sink ELF-specific getSectionPrefixForUniqueGlobal impl into
ELFTargetAsmInfo.
4. Fix SectionFlagsForGlobal to know that BSS/ThreadBSS has the
BSS bit set (the real fix for PR4619).
5. Fix isSuitableForBSS to not put globals with explicit sections
set in BSS (which was the reason #4 wasn't fixed earlier).
6. Remove my previous hack for PR4619.
llvm-svn: 77085
- Some clients which used DOUT have moved to DEBUG. We are deprecating the
"magic" DOUT behavior which avoided calling printing functions when the
statement was disabled. In addition to being unnecessary magic, it had the
downside of leaving code in -Asserts builds, and of hiding potentially
unnecessary computations.
llvm-svn: 77019
%0 = malloc [3758096384 x i32]
The "malloc" instruction doesn't support 64-bits correctly (see PR715),
and should be removed. Victor is actively working on fixing this, in
the meantime just don't crash.
llvm-svn: 76899
- Yay for '-'s and simplifications!
- I kept StringMap::GetOrCreateValue for compatibility purposes, this can
eventually go away. Likewise the StringMapEntry Create functions still follow
the old style.
- NIFC.
llvm-svn: 76888
a new getSectionForMergableConstant hook. This removes one dependence
of TAI on Type, and provides the hook with enough info to make the
right decision based on whether the global has relocations etc.
llvm-svn: 76705
This is considered a workaround. The problem is some targets are not modeling side effects correctly. PPC is apparently one of those. This patch allows ppc llvm-gcc to bootstrap on Darwin. Once we find out which instruction definitions are wrong, we can remove the PPCInstrInfo workaround.
llvm-svn: 76703
Constant::getRelocationInfo(), which has a much simpler
to use API. It still should not be part of libvmcore, but
is better than it was. Also teach it to be smart about
hidden visibility.
llvm-svn: 76700
range's weight properly. This is turned off right now in the sense that
you'll get an assert if you get into a situation that can only be caused
by an iterative coalescer. All other code paths operate exactly as
before so there is no functional change with this patch. The asserts
should be disabled if/when an iterative coalescer gets added to trunk.
llvm-svn: 76680
pool entry will require relocations against it. I implemented this
conservatively for ARM, someone who is knowledgable about it should
see if this can be improved.
llvm-svn: 76678
their appropriate sections before the code itself. They need to be emitted
before the function because on some targets (x86 but not x86_64) the later
may reference a JT or CP entry address
llvm-svn: 76672
be useful, and it's currently unused. (Some issues: it isn't actually
rich enough to capture the semantics on many architectures, and
semantics can vary depending on the type being shifted.)
llvm-svn: 76633
"LinkerPrivatePrefix". It seems to have been used in only one place before I
started this "linker_private" business. I'm thinking that a rename is in
order...
llvm-svn: 76479
"private" symbols which the assember shouldn't strip, but which the linker may
remove after evaluation. This is mostly useful for Objective-C metadata.
This is plumbing, so we don't have a use of it yet. More to come, etc.
llvm-svn: 76385
Inline asm instructions may have additional <imp-def,kill> register operands.
These operands are not marked with a flag like the normal asm operands, so we
must not assert that there is a flag.
llvm-svn: 76373
starting in getCurrentFunctionEHName. Among other problems,
we would try to privative a "foo.eh" label, but end up emitting
the label as _Lfoo.eh instead of L_foo.eh on darwin. This is really
bad, and the linker has always tolerated these labels existing.
For now, just emit them as _foo.eh.
This patch also fixes problems with ".eh" labels on unnamed
functions and eliminates two strangely defined TargetAsmInfo
hooks.
llvm-svn: 76231
stack alignment right when it is. This is not
ideal but conservatively correct. Adjust a test
to compensate for changed stack offset value.
gcc.apple/asm-block-57.c
llvm-svn: 76120
call to the MachineCodeEmitter interface and made copying the start
line of a function not conditional on whether we're emitting Dwarf
debug information. I'll propagate the processDebugLoc() calls to the
non-X86 targets in a followup patch.
In the long run, it'll probably be better to gather this information
through the DwarfWriter, but the DwarfWriter currently depends on the
AsmPrinter and TargetAsmInfo, and fixing that would be out of the way
for this patch.
There's a bug in OProfile 0.9.4 that makes it ignore line numbers for
addresses above 4G, and a patch fixing it at
http://thread.gmane.org/gmane.linux.oprofile/7634
Sample output:
$ sudo opcontrol --reset; sudo opcontrol --start-daemon; sudo opcontrol --start; `pwd`/Debug/bin/lli fib.bc; sudo opcontrol --stop
Signalling daemon... done
Profiler running.
fib(40) == 165580141
Stopping profiling.
$ opreport -g -d -l `pwd`/Debug/bin/lli|head -60
Overflow stats not available
CPU: Core 2, speed 1998 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (Unhalted core cycles) count 100000
vma samples % linenr info image name symbol name
00007f67a30370b0 25489 61.2554 fib.c:24 10946.jo fib_left
00007f67a30370b0 1634 6.4106 fib.c:24
00007f67a30370b1 83 0.3256 fib.c:24
00007f67a30370b9 1997 7.8348 fib.c:24
00007f67a30370c6 2080 8.1604 fib.c:27
00007f67a30370c8 988 3.8762 fib.c:27
00007f67a30370cd 1315 5.1591 fib.c:27
00007f67a30370cf 251 0.9847 fib.c:27
00007f67a30370d3 1191 4.6726 fib.c:27
00007f67a30370d6 975 3.8252 fib.c:27
00007f67a30370db 1010 3.9625 fib.c:27
00007f67a30370dd 242 0.9494 fib.c:27
00007f67a30370e1 2782 10.9145 fib.c:28
00007f67a30370e5 3768 14.7828 fib.c:28
00007f67a30370eb 615 2.4128 (no location information)
00007f67a30370f3 6558 25.7287 (no location information)
00007f67a3037100 15603 37.4973 fib.c:29 10946.jo fib_right
00007f67a3037100 1646 10.5493 fib.c:29
00007f67a3037101 45 0.2884 fib.c:29
00007f67a3037109 2372 15.2022 fib.c:29
00007f67a3037116 2234 14.3178 fib.c:32
00007f67a3037118 612 3.9223 fib.c:32
00007f67a303711d 622 3.9864 fib.c:32
00007f67a303711f 385 2.4675 fib.c:32
00007f67a3037123 404 2.5892 fib.c:32
00007f67a3037126 634 4.0633 fib.c:32
00007f67a303712b 870 5.5759 fib.c:32
00007f67a303712d 62 0.3974 fib.c:32
00007f67a3037131 1848 11.8439 fib.c:33
00007f67a3037135 2840 18.2016 fib.c:33
00007f67a303713a 1 0.0064 fib.c:33
00007f67a303713b 1023 6.5564 (no location information)
00007f67a3037143 5 0.0320 (no location information)
000000000080c1e4 15 0.0360 MachineOperand.h:150 lli llvm::MachineOperand::isReg() const
000000000080c1e4 6 40.0000 MachineOperand.h:150
000000000080c1ec 2 13.3333 MachineOperand.h:150
...
llvm-svn: 76102
The inline asm operands must be parsed from the first flag, you cannot assume
that an immediate operand preceeding a register use operand is the flag.
PowerPC "m" operands are represented as (flag, imm, reg) triples.
isRegTiedToDefOperand() would incorrectly interpret the imm as the flag.
llvm-svn: 76101
This extra check is not trigged when runnning "make check" on top-of-tree.
Change error message to better match llvm_unreachable() grammar.
Don't call llvm_unreachable() when writing error messages to a file, but keep going.
llvm-svn: 75860
Reserved registers are not candidates for scavenging, and they were removed
from the candidate list like this:
CreateRegClassMask(RC, Candidates);
Candidates ^= ReservedRegs;
However, when there are reserved registers outside RC, this causes invalid
bits to be set in Candidates.
llvm-svn: 75847
additional bug fixes:
1. The bug that everyone hit was a problem in the asmprinter where it
would remove $stub but keep the L prefix on a name when emitting the
indirect symbol. This is easy to fix by keeping the name of the stub
and the name of the symbol in a StringMap instead of just keeping a
StringSet and trying to reconstruct it late.
2. There was a problem printing the personality function. The current
logic to print out the personality function from the DWARF information
is a bit of a cesspool right now that duplicates a bunch of other
logic in the asm printer. The short version of it is that it depends
on emitting both the L and _ prefix for symbols (at least on darwin)
and until I can untangle it, it is best to switch the mangler back to
emitting both prefixes.
llvm-svn: 75646
This adds location info for all llvm_unreachable calls (which is a macro now) in
!NDEBUG builds.
In NDEBUG builds location info and the message is off (it only prints
"UREACHABLE executed").
llvm-svn: 75640
--- Reverse-merging r75619 into '.':
U lib/Target/DarwinTargetAsmInfo.cpp
U lib/CodeGen/AsmPrinter/AsmPrinter.cpp
--- Reverse-merging r75618 into '.':
U lib/CodeGen/ELFWriter.cpp
U lib/CodeGen/MachOCodeEmitter.cpp
U lib/CodeGen/MachOWriter.cpp
--- Reverse-merging r75617 into '.':
U lib/Target/CBackend/CBackend.cpp
--- Reverse-merging r75616 into '.':
U tools/bugpoint/Miscompilation.cpp
U tools/lto/LTOCodeGenerator.cpp
U tools/lto/LTOModule.cpp
llvm-svn: 75638
indicates whether the label is private or not, instead of taking
prefix stuff. One effect of this is that symbols will be generated
with *just* the private prefix, instead of both the private prefix
*and* the user-label-prefix, but this doesn't matter as long as it
is consistent. For example we'll now get "Lfoo" instead of "L_foo".
These are just assembler temporary labels anyway, so they never even
make it into the .o file.
llvm-svn: 75607
and related functions out of LoopBase and into Loop, since they
are specific to BasicBlock-based loops. This also allows the code
to be moved out-of-line.
llvm-svn: 75523
using the Curiously Recurring Template Pattern with LoopBase.
This will help further refactoring, and future functionality for
Loop. Also, Headers can now foward-declare Loop, instead of pulling
in LoopInfo.h or doing tricks.
llvm-svn: 75519
We'll eventually use this to print comments in asm files and do other
fun things.
This adds interfaces to the AsmPrinter and changes TableGen to invoke
the postInstructionAction when appropriate. It also add parameters to
TargetAsmInfo to control comment layout.
llvm-svn: 75490
This involves temporarily hard wiring some parts to use the global context. This isn't ideal, but it's
the only way I could figure out to make this process vaguely incremental.
llvm-svn: 75445
implemented in codegen, have no frontend to generate them, and are
better implemented with pattern matching (like the ppc backend does
to generate rlwimi/rlwinm etc).
PR4543
llvm-svn: 75430
Make llvm_unreachable take an optional string, thus moving the cerr<< out of
line.
LLVM_UNREACHABLE is now a simple wrapper that makes the message go away for
NDEBUG builds.
llvm-svn: 75379
hooks as they're no longer needed.
The major change with this patch is to make formatted_raw_ostream usable
by any client of raw_ostream.
llvm-svn: 75283
value. Adjust other code to deal with that correctly. Make
DAGTypeLegalizer::PromoteIntRes_EXTRACT_VECTOR_ELT take advantage of
this new flexibility to simplify the code and make it deal with unusual
vectors (like <4 x i1>) correctly. Fixes PR3037.
llvm-svn: 75176
registers based on dynamic conditions. For example, X86 EBP/RBP, when used as
frame register has to be spilled in the first fixed object. It should inform
PEI this so it doesn't get allocated another stack object. Also, it should not
be spilled as other callee-saved registers but rather its spilling and restoring
are being handled by emitPrologue and emitEpilogue. Avoid spilling it twice.
llvm-svn: 75116
as an (index,bool) pair. The bool flag records whether the kill is a
PHI kill or not. This code will be used to enable splitting of live
intervals containing PHI-kills.
A slight change to live interval weights introduced an extra spill
into lsr-code-insertion (outside the critical sections). The test
condition has been updated to reflect this.
llvm-svn: 75097
nodes with operand types that differ from the result type. (This
doesn't normally happen right now, because
SelectionDAGLowering::visitShuffleVector normalizes vector shuffles.)
llvm-svn: 75081
VSETCC must define all bits, which is different than it was documented
to before. Since all targets that implement VSETCC already have this
behavior, and we don't optimize based on this, just change the
documentation. We now get nice code for vec_compare.ll
llvm-svn: 74978
as "X" constraint and "P" modifier on x86. Make this work.
(Change may not be sufficient to fix it for non-Darwin, but
I'm pretty sure it won't break anything.)
gcc.apple/asm-block-32.c
gcc.apple/asm-block-33.c
llvm-svn: 74967
previous cmp; a copy can not be inserted here if the copy insn also has
side effects. We don't have access to the attributes of copy insn here;
so just play safe by finding a safe locations for branch terminators.
llvm-svn: 74898
With the SVR4 ABI on PowerPC, vector arguments for vararg calls are passed differently depending on whether they are a fixed or a variable argument. Variable vector arguments always go into memory, fixed vector arguments are put
into vector registers. If there are no free vector registers available, fixed vector arguments are put on the stack.
The NumFixedArgs attribute allows to decide for an argument in a vararg call whether it belongs to the fixed or variable portion of the parameter list.
llvm-svn: 74764
Note, isUndef marker must be placed even on implicit_def def operand or else the scavenger will not ignore it. This is necessary because -O0 path does not use liveintervalanalysis, it treats implicit_def just like any other def.
llvm-svn: 74601
have the alignment be calculated up front, and have the back-ends obey whatever
alignment is decided upon.
This allows for future work that would allow for precise no-op placement and the
like.
llvm-svn: 74564
The register allocator, when it allocates a register to a virtual register defined by an implicit_def, can allocate any physical register without worrying about overlapping live ranges. It should mark all of operands of the said virtual register so later passes will do the right thing.
This is not the best solution. But it should be a lot less fragile to having the scavenger try to track what is defined by implicit_def.
llvm-svn: 74518
the SelectionDAG::getGlobalAddress function properly looks through
aliases to determine thread-localness, but then passes the GV* down
to GlobalAddressSDNode::GlobalAddressSDNode which does not. Instead
of passing down isTarget, just pass down the predetermined node
opcode. This fixes some assertions with out of tree changes I'm
working on.
llvm-svn: 74325
to be shared, but how/where to privatize it is not immediately clear to me.
If any SelectionDAG experts see a better solution, please share!
llvm-svn: 74180
This change doubles the allowable value for MVT::LAST_VALUETYPE. It does
this by doing several things.
1. Introduces MVT::MAX_ALLOWED_LAST_VALUETYPE which in this change has a
value of 64. This value contains the current maximum for the
MVT::LAST_VALUETYPE.
2. Instead of checking "MVT::LAST_VALUETYPE <= 32", all of those uses
now become "MVT::LAST_VALUETYPE <= MVT::MAX_ALLOWED_LAST_VALUETYPE"
3. Changes the dimension of the ValueTypeActions from 2 elements to four
elements and adds comments ahead of the declaration indicating the it is
"(MVT::MAX_ALLOWED_LAST_VALUETYPE/32) * 2". This at least lets us find
what is affected if and when MVT::MAX_ALLOWED_LAST_VALUETYPE gets
changed.
4. Adds initializers for the new elements of ValueTypeActions.
This does NOT add any types in MVT. That would be done separately.
This doubles the size of ValueTypeActions from 64 bits to 128 bits and
gives us the freedom to add more types for AVX.
llvm-svn: 74110
Only pad when the section size > 0 and move the code that deals
with globals initializers to a place we know for sure the global
is initialized.
llvm-svn: 73944
Support for .text relocations, implementing TargetELFWriter overloaded methods for x86/x86_64.
Use a map to track global values to their symbol table indexes
Code cleanup and small fixes
llvm-svn: 73894
- Register allocator should resolve the second part of the hint (register number) before passing it to the target since it knows virtual register to physical register mapping.
- More fixes to get ARM load / store double word working.
llvm-svn: 73671
TurnCopyIntoImpDef turns a copy into implicit_def and remove the val# defined by it. This causes an scavenger assertion later if the def reaches other blocks. Disable the transformation if the value live interval extends beyond its def block.
llvm-svn: 73478
support for x86, and UMULO/SMULO for many architectures, including PPC
(PR4201), ARM, and Cell. The resulting expansion isn't perfect, but it's
not bad.
llvm-svn: 73477
incomming chain of the RETURN node. The incomming chain must
be the outgoing chain of the CALL node. This causes the
backend to identify tail calls that are not tail calls. This
patch fixes this.
llvm-svn: 73387
- Change register allocation hint to a pair of unsigned integers. The hint type is zero (which means prefer the register specified as second part of the pair) or entirely target dependent.
- Allow targets to specify alternative register allocation orders based on allocation hint.
Part 2.
- Use the register allocation hint system to implement more aggressive load / store multiple formation.
- Aggressively form LDRD / STRD. These are formed *before* register allocation. It has to be done this way to shorten live interval of base and offset registers. e.g.
v1025 = LDR v1024, 0
v1026 = LDR v1024, 0
=>
v1025,v1026 = LDRD v1024, 0
If this transformation isn't done before allocation, v1024 will overlap v1025 which means it more difficult to allocate a register pair.
- Even with the register allocation hint, it may not be possible to get the desired allocation. In that case, the post-allocation load / store multiple pass must fix the ldrd / strd instructions. They can either become ldm / stm instructions or back to a pair of ldr / str instructions.
This is work in progress, not yet enabled.
llvm-svn: 73381
consecutive addresses togther. This makes it easier for the post-allocation pass
to form ldm / stm.
This is step 1. We are still missing a lot of ldm / stm opportunities because
of register allocation are not done in the desired order. More enhancements
coming.
llvm-svn: 73291
Emission for globals, using the correct data sections
Function alignment can be computed for each target using TargetELFWriterInfo
Some small fixes
llvm-svn: 73201
on x86 to handle more cases. Fix a bug in said code that would cause it
to read past the end of an object. Rewrite the code in
SelectionDAGLegalize::ExpandBUILD_VECTOR to be a bit more general.
Remove PerformBuildVectorCombine, which is no longer necessary with
these changes. In addition to simplifying the code, with this change,
we can now catch a few more cases of consecutive loads.
llvm-svn: 73012
integer type to be consistent with normal operation legalization. No visible
change because nothing is actually using this at the moment.
llvm-svn: 72980
Update code generator to use this attribute and remove NoImplicitFloat target option.
Update llc to set this attribute when -no-implicit-float command line option is used.
llvm-svn: 72959
build vectors with i64 elements will only appear on 32b x86 before legalize.
Since vector widening occurs during legalize, and produces i64 build_vector
elements, the dag combiner is never run on these before legalize splits them
into 32b elements.
Teach the build_vector dag combine in x86 back end to recognize consecutive
loads producing the low part of the vector.
Convert the two uses of TLI's consecutive load recognizer to pass LoadSDNodes
since that was required implicitly.
Add a testcase for the transform.
Old:
subl $28, %esp
movl 32(%esp), %eax
movl 4(%eax), %ecx
movl %ecx, 4(%esp)
movl (%eax), %eax
movl %eax, (%esp)
movaps (%esp), %xmm0
pmovzxwd %xmm0, %xmm0
movl 36(%esp), %eax
movaps %xmm0, (%eax)
addl $28, %esp
ret
New:
movl 4(%esp), %eax
pmovzxwd (%eax), %xmm0
movl 8(%esp), %eax
movaps %xmm0, (%eax)
ret
llvm-svn: 72957
integer and floating-point opcodes, introducing
FAdd, FSub, and FMul.
For now, the AsmParser, BitcodeReader, and IRBuilder all preserve
backwards compatability, and the Core LLVM APIs preserve backwards
compatibility for IR producers. Most front-ends won't need to change
immediately.
This implements the first step of the plan outlined here:
http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt
llvm-svn: 72897
using Promote which won't work because i64 isn't
a legal type. It's easy enough to use Custom, but
then we have the problem that when the type
legalizer is promoting FP_TO_UINT->i16, it has no
way of telling it should prefer FP_TO_SINT->i32
to FP_TO_UINT->i32. I have uncomfortably hacked
this by making the type legalizer choose FP_TO_SINT
when both are Custom.
This fixes several regressions in the testsuite.
llvm-svn: 72891
instcombine doesn't know when it's safe. To partially compensate
for this, introduce new code to do this transformation in
dagcombine, which can use UnsafeFPMath.
llvm-svn: 72872
EAX = ..., AX<imp-def>
...
= AX
This creates a double-def. Apparently this used to be necessary but is no longer needed.
Thanks to Anton for pointing this out. Anton, I cannot create a test case without your uncommitted ARM patches. Please check in a test case for me.
llvm-svn: 72755
one new .cpp file, in preparation for merging in the Direct Object Emission
changes we're working on. No functional changes.
Fixed coding style issues on the original patch. Patch by Aaron Gray
llvm-svn: 72754
ADDC/ADDE use MVT::i1 (later, whatever it gets legalized to)
instead of MVT::Flag. Remove CARRY_FALSE in favor of 0; adjust
all target-independent code to use this format.
Most targets will still produce a Flag-setting target-dependent
version when selection is done. X86 is converted to use i32
instead, which means TableGen needs to produce different code
in xxxGenDAGISel.inc. This keys off the new supportsHasI1 bit
in xxxInstrInfo, currently set only for X86; in principle this
is temporary and should go away when all other targets have
been converted. All relevant X86 instruction patterns are
modified to represent setting and using EFLAGS explicitly. The
same can be done on other targets.
The immediate behavior change is that an ADC/ADD pair are no
longer tightly coupled in the X86 scheduler; they can be
separated by instructions that don't clobber the flags (MOV).
I will soon add some peephole optimizations based on using
other instructions that set the flags to feed into ADC.
llvm-svn: 72707
failure during llvm-gcc bootstrap:
Assertion failed: (!Tmp2.getNode() && "Can't legalize BR_CC with legal condition!"), function ExpandNode, file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 2923.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c:1727: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
llvm-svn: 72530
This is basically the end of this series of patches for LegalizeDAG; the
remaining special cases can't be removed without more infrastructure
work. There's a FIXME for each relevant opcode near the beginning of
SelectionDAGLegalize::LegalizeOp.
llvm-svn: 72514
e.g.
orl $65536, 8(%rax)
=>
orb $1, 10(%rax)
Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.
llvm-svn: 72507
entries as there are basic blocks in the function. LiveVariables::getVarInfo
creates a VarInfo struct for every register in the function, leading to
quadratic space use. This patch changes the BitVector to a SparseBitVector,
which doesn't help the worst-case memory use but does reduce the actual use in
very long functions with short-lived variables.
llvm-svn: 72426
doesn't split legal vector operands. This is necessary because the
type legalization (and therefore, vector splitting) code will be going
away soon.
llvm-svn: 72349
The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.
llvm-svn: 72331
will allow simplifying LegalizeDAG to eliminate type legalization. (I
have a patch to do that, but it's not quite finished; I'll commit it
once it's finished and I've fixed any review comments for this patch.)
See the comment at the beginning of
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp for more details on the
motivation for this patch.
llvm-svn: 72325
code in preparation for code generation. The main thing it does
is handle the case when eh.exception calls (and, in a future
patch, eh.selector calls) are far away from landing pads. Right
now in practice you only find eh.exception calls close to landing
pads: either in a landing pad (the common case) or in a landing
pad successor, due to loop passes shifting them about. However
future exception handling improvements will result in calls far
from landing pads:
(1) Inlining of rewinds. Consider the following case:
In function @f:
...
invoke @g to label %normal unwind label %unwinds
...
unwinds:
%ex = call i8* @llvm.eh.exception()
...
In function @g:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
"rethrow exception"
Now inline @g into @f. Currently this is turned into:
In function @f:
...
invoke @something to label %continue unwind label %handler
...
handler:
%ex = call i8* @llvm.eh.exception()
... perform cleanups ...
invoke "rethrow exception" to label %normal unwind label %unwinds
unwinds:
%ex = call i8* @llvm.eh.exception()
...
However we would like to simplify invoke of "rethrow exception" into
a branch to the %unwinds label. Then %unwinds is no longer a landing
pad, and the eh.exception call there is then far away from any landing
pads.
(2) Using the unwind instruction for cleanups.
It would be nice to have codegen handle the following case:
invoke @something to label %continue unwind label %run_cleanups
...
handler:
... perform cleanups ...
unwind
This requires turning "unwind" into a library call, which
necessarily takes a pointer to the exception as an argument
(this patch also does this unwind lowering). But that means
you are using eh.exception again far from a landing pad.
(3) Bugpoint simplifications. When bugpoint is simplifying
exception handling code it often generates eh.exception calls
far from a landing pad, which then causes codegen to assert.
Bugpoint then latches on to this assertion and loses sight
of the original problem.
Note that it is currently rare for this pass to actually do
anything. And in fact it normally shouldn't do anything at
all given the code coming out of llvm-gcc! But it does fire
a few times in the testsuite. As far as I can see this is
almost always due to the LoopStrengthReduce codegen pass
introducing pointless loop preheader blocks which are landing
pads and only contain a branch to another block. This other
block contains an eh.exception call. So probably by tweaking
LoopStrengthReduce a bit this can be avoided.
llvm-svn: 72276
the 'constract function dbg thingy'. Rename some methods to make them consistent
with the rest of the methods. Move the 'Emit' methods to the end of the file.
llvm-svn: 72192
build an integer and cast that to a float. This fixes a crash
caused by trying to split an f32 into two f16's.
This changes the behavior in test/CodeGen/XCore/fneg.ll because that
testcase now triggers a DAGCombine which converts the fneg into an integer
operation. If someone is interested, it's probably possible to tweak
the test to generate an actual fneg.
llvm-svn: 72162
function, this could be many, many times. We don't want to re-add variables to
that DIE for each time. We just want to add them once. Check to make sure that
we haven't added them already.
llvm-svn: 72047
The following is checked:
* Operand counts: All explicit operands must be present.
* Register classes: All physical and virtual register operands must be
compatible with the register class required by the instruction descriptor.
* Register live intervals: Registers must be defined only once, and must be
defined before use.
The machine code verifier is enabled with the command-line option
'-verify-machineinstrs', or by defining the environment variable
LLVM_VERIFY_MACHINEINSTRS to the name of a file that will receive all the
verifier errors.
llvm-svn: 71918
Owen Anderson