MC disassembler clients (LLDB) are interested in querying if an
instruction may affect control flow other than by virtue of being
an explicit branch instruction. For example, instructions which
write directly to the PC on some architectures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170610 91177308-0d34-0410-b5e6-96231b3b80d8
These were defined on TargetRegisterInfo, but they don't use any information
that's not available in MCRegisterInfo, so sink them down to be available
at the MC layer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170608 91177308-0d34-0410-b5e6-96231b3b80d8
Use the version that also takes an MF reference instead.
It would technically be possible to extract an MF reference from the MI
as MI->getParent()->getParent(), but that would not work for MIs that
are not inserted into any basic block.
Given the reasonably small number of places this constructor was used at
all, I preferred the compile time check to a run time assertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170588 91177308-0d34-0410-b5e6-96231b3b80d8
Just like for addMemOperand(), the function pointer provides a context
for allocating memory. This will make it possible to use a better memory
allocation strategy for the MI operand list, which is currently a slow
std::vector.
Most calls to addOperand() come from MachineInstrBuilder, so give that
class an MF reference as well. Code using BuildMI() won't need changing
at all since the MF reference is already required to allocate a
MachineInstr.
Future patches will fix code that calls MI::addOperand(Op) directly, as
well as code that uses the now deprecated MachineInstrBuilder(MI)
constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170574 91177308-0d34-0410-b5e6-96231b3b80d8
- An MVT can become an EVT when being split (e.g. v2i8 -> v1i8, the latter doesn't exist)
- Return the scalar value when an MVT is scalarized (v1i64 -> i64)
Fixes PR14639ff.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170546 91177308-0d34-0410-b5e6-96231b3b80d8
I cannot reproduce it the failures locally, so I will keep an eye at the ppc
bots. This patch does add the change to the "Disassembly of section" message,
but that is not what was failing on the bots.
Original message:
Add a funciton to get the segment name of a section.
On MachO, sections also have segment names. When a tool looking at a .o file
prints a segment name, this is what they mean. In reality, a .o has only one
anonymous, segment.
This patch adds a MachO only function to fetch that segment name. I named it
getSectionFinalSegmentName since the main use for the name seems to be infor
the linker with segment this section should go to.
The patch also changes MachOObjectFile::getSectionName to return just the
section name instead of computing SegmentName,SectionName.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170545 91177308-0d34-0410-b5e6-96231b3b80d8
The bundle flags are now maintained by the slightly higher-level
functions bundleWithPred() / bundleWithSucc() which enforce consistent
bundle flags between neighboring instructions.
See also MIBundleBuilder for an even higher-level approach to building
bundles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170475 91177308-0d34-0410-b5e6-96231b3b80d8
The bundle_iterator::operator++ function now doesn't need to dig out the
basic block and check against end(). It can use the isBundledWithSucc()
flag to find the last bundled instruction safely.
Similarly, MachineInstr::isBundled() no longer needs to look at
iterators etc. It only has to look at flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170473 91177308-0d34-0410-b5e6-96231b3b80d8
The bundle-related MI flags need to be kept in sync with the neighboring
instructions. Don't allow the bulk flag-setting setFlags() function to
change them.
Also don't copy MI flags when cloning an instruction. The clone's bundle
flags will be set when it is explicitly inserted into a bundle.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170459 91177308-0d34-0410-b5e6-96231b3b80d8
Remove the instr_iterator versions of the splice() functions. It doesn't
seem useful to be able to splice sequences of instructions that don't
consist of full bundles.
The normal splice functions that take MBB::iterator arguments are not
changed, and they can move whole bundles around without any problems.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170456 91177308-0d34-0410-b5e6-96231b3b80d8
The single-element ilist::splice() function supports a noop move:
List.splice(I, List, I);
The corresponding std::list function doesn't allow that, so add a unit
test to document that behavior.
This also means that
List.splice(I, List, F);
is somewhat surprisingly not equivalent to
List.splice(I, List, F, next(F));
This patch adds an assertion to catch the illegal case I == F above.
Alternatively, we could make I == F a legal noop, but that would make
ilist differ even more from std::list.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170443 91177308-0d34-0410-b5e6-96231b3b80d8
The normal insert() function takes an MBB::iterator position, and
inserts a stand-alone MachineInstr as before.
The insert() function that takes an MBB::instr_iterator position can
insert instructions inside a bundle, and will now update the bundle
flags correctly when that happens.
When the insert position is between two bundles, it is unclear whether
the instruction should be appended to the previous bundle, prepended to
the next bundle, or stand on its own. The MBB::insert() function doesn't
bundle the instruction in that case, use the MIBundleBuilder class for
that.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170437 91177308-0d34-0410-b5e6-96231b3b80d8
Most code is oblivious to bundles and uses the MBB::iterator which only
visits whole bundles. MBB::erase() operates on whole bundles at a time
as before.
MBB::remove() now refuses to remove bundled instructions. It is not safe
to remove all instructions in a bundle without deleting them since there
is no way of returning pointers to all the removed instructions.
MBB::remove_instr() and MBB::erase_instr() will now update bundle flags
correctly, lifting individual instructions out of bundles while leaving
the remaining bundle intact.
The MachineInstr convenience functions are updated so
eraseFromParent() erases a whole bundle as before
eraseFromBundle() erases a single instruction, leaving the rest of its bundle.
removeFromParent() refuses to operate on bundled instructions, and
removeFromBundle() lifts a single instruction out of its bundle.
These functions will no longer accidentally split or coalesce bundles -
bundle flags are updated to preserve the existing bundling, and explicit
bundleWith* / unbundleFrom* functions should be used to change the
instruction bundling.
This API update is still a work in progress. I am going to update APIs
first so they maintain bundle flags automatically when possible. Then
I'll add stricter verification of the bundle flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170384 91177308-0d34-0410-b5e6-96231b3b80d8
compilation directory.
This defaults to the current working directory, just as it always has,
but now an assembler can choose to override it with a custom directory.
I've taught llvm-mc about this option and added a test case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170371 91177308-0d34-0410-b5e6-96231b3b80d8
Mips16 is really a processor decoding mode (ala thumb 1) and in the same
program, mips16 and mips32 functions can exist and can call each other.
If a jal type instruction encounters an address with the lower bit set, then
the processor switches to mips16 mode (if it is not already in it). If the
lower bit is not set, then it switches to mips32 mode.
The linker knows which functions are mips16 and which are mips32.
When relocation is performed on code labels, this lower order bit is
set if the code label is a mips16 code label.
In general this works just fine, however when creating exception handling
tables and dwarf, there are cases where you don't want this lower order
bit added in.
This has been traditionally distinguished in gas assembly source by using a
different syntax for the label.
lab1: ; this will cause the lower order bit to be added
lab2=. ; this will not cause the lower order bit to be added
In some cases, it does not matter because in dwarf and debug tables
the difference of two labels is used and in that case the lower order
bits subtract each other out.
To fix this, I have added to mcstreamer the notion of a debuglabel.
The default is for label and debug label to be the same. So calling
EmitLabel and EmitDebugLabel produce the same result.
For various reasons, there is only one set of labels that needs to be
modified for the mips exceptions to work. These are the "$eh_func_beginXXX"
labels.
Mips overrides the debug label suffix from ":" to "=." .
This initial patch fixes exceptions. More changes most likely
will be needed to DwarfCFException to make all of this work
for actual debugging. These changes will be to emit debug labels in some
places where a simple label is emitted now.
Some historical discussion on this from gcc can be found at:
http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00623.htmlhttp://gcc.gnu.org/ml/gcc-patches/2008-11/msg01273.html
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170279 91177308-0d34-0410-b5e6-96231b3b80d8
