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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77691 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77661 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77582 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77504 91177308-0d34-0410-b5e6-96231b3b80d8
correct. But what are you going to do? I'll fix this in the future.
- Move another large loop into its own method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77408 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77294 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77085 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77019 91177308-0d34-0410-b5e6-96231b3b80d8
%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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76899 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76888 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76705 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76703 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76700 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76680 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76678 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76672 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76633 91177308-0d34-0410-b5e6-96231b3b80d8
"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...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76479 91177308-0d34-0410-b5e6-96231b3b80d8
are referenced, ignore the relocation entry and patch the relocatable field with
the computed symbol offset directly
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@76414 91177308-0d34-0410-b5e6-96231b3b80d8
