* Remove dead methods.
* Use the 'operator==' method instead of 'contains', which isn't needed.
* Fix some comments.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171523 91177308-0d34-0410-b5e6-96231b3b80d8
This patch fixes the PPC eh_frame definitions for the personality and
frame unwinding for PIC objects. It makes PIC build correctly creates
relative relocations in the '.rela.eh_frame' segments and thus avoiding
a text relocation that generates a DT_TEXTREL segments in link phase.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171506 91177308-0d34-0410-b5e6-96231b3b80d8
1. Add code to estimate register pressure.
2. Add code to select the unroll factor based on register pressure.
3. Add bits to TargetTransformInfo to provide the number of registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171469 91177308-0d34-0410-b5e6-96231b3b80d8
Users of LLVM_BUILTIN_UNREACHABLE should be responsible in the case when LLVM_BUILTIN_UNREACHABLE is undefined.
Actually, (0, (p)) in LLVM_ASSUME_ALIGNED(p, a) caused thousands of warnings on g++-4.4. It was a motivation in this commit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171455 91177308-0d34-0410-b5e6-96231b3b80d8
In order to cost subvector insertion and extraction, we need to know
the type of the subvector being extracted.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171453 91177308-0d34-0410-b5e6-96231b3b80d8
before the last time.
--- Reverse-merging r171442 into '.':
U include/llvm/IR/Attributes.h
U lib/IR/Attributes.cpp
U lib/IR/AttributeImpl.h
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171448 91177308-0d34-0410-b5e6-96231b3b80d8
When Kind == (Broadcast or Reverse) then Index is not used; make it an optional parameter.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171447 91177308-0d34-0410-b5e6-96231b3b80d8
The 'operator==' method is a bit clearer and much less verbose for somethings
that should have only one value. Remove from the AttrBuilder for consistency.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171442 91177308-0d34-0410-b5e6-96231b3b80d8
Modify the AttrBuilder class to store the attributes as a set instead of as a
bit mask. The Attribute class will represent only one attribute instead of a
collection of attributes.
This is the wave of the future!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171427 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes Valgrind failures and removes bitwise operations that don't provide any benefit.
Valgrind failures reported by NAKAMURA Takumi.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171413 91177308-0d34-0410-b5e6-96231b3b80d8
* Add support for specifying the alignment to use.
* Add the concept of native endianness. Used for unaligned native types.
The native alignment and read/write simplification is based on a patch by Richard Smith.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171406 91177308-0d34-0410-b5e6-96231b3b80d8
code that includes Intrinsics.gen directly.
This never showed up in my testing because the old Intrinsics.gen was
still kicking around in the make build system and was correct there. =[
Thankfully, some of the bots to clean rebuilds and that caught this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171373 91177308-0d34-0410-b5e6-96231b3b80d8
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.
There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.
The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.
I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).
I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171366 91177308-0d34-0410-b5e6-96231b3b80d8
utils/sort_includes.py script.
Most of these are updating the new R600 target and fixing up a few
regressions that have creeped in since the last time I sorted the
includes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171362 91177308-0d34-0410-b5e6-96231b3b80d8
through the static helper functions. This is already true throughout the
codebase.
Slowly, I'm going to re-implement these static helpers in terms of a new
process based interface which can expose more information, and remove
the program object entirely.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171335 91177308-0d34-0410-b5e6-96231b3b80d8
Implement the old API in terms of the new one. This simplifies the
implementation on Windows which can now re-use the self_process's once
initialization.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171330 91177308-0d34-0410-b5e6-96231b3b80d8
a union. These don't actually work for by-value function arguments, and
MSVC warns if they exist even while (we hope) it aligns the argument
correctly due to the other union member.
This means MSVC will miss out on optimizations based on the alignment of
the buffer, but really, there aren't that many for x86 and MSVC is
likely not doing a great job of optimizing LLVM and Clang anyways.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171328 91177308-0d34-0410-b5e6-96231b3b80d8
This adds AlignedCharArray<Alignment, Size>. A templated struct that contains
a member named buffer of type char[Size] that is aligned to Alignment.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171319 91177308-0d34-0410-b5e6-96231b3b80d8
The coding style used here is not LLVM's style because this is modeled
after a Boost interface and thus done in the style of a candidate C++
standard library interface. I'll probably end up proposing it as
a standard C++ library if it proves to be reasonably portable and
useful.
This is just the most basic parts of the interface -- getting the
process ID out of it. However, it helps sketch out some of the boiler
plate such as the base class, derived class, shared code, and static
factory function. It also introduces a unittest so that I can
incrementally ensure this stuff works.
However, I've not even compiled this code for Windows yet. I'll try to
fix any Windows fallout from the bots, and if I can't fix it I'll revert
and get someone on Windows to help out. There isn't a lot more that is
mandatory, so soon I'll switch to just stubbing out the Windows side and
get Michael Spencer to help with implementation as he can test it
directly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171289 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM libraries. Also, clean up the doxygen and formatting of the
existing interfaces.
With this change I'm calling the existing interface "legacy" because I'd
like to replace it with something much better. My end goal is to expose
a common set of interfaces for inspecting various properties of
a process, and implementations to expose those both for the current
process and for child processes. This will also expose more rich
interfaces for spawning and controling a subprocess, notably to use
system calls like wait3 and wait4 where available and gather detailed
resource usage stats about the subprocess.
My plan (discussed with Michael Spencer on IRC) is to base this loosely
around the proposed Boost.Process interface, but to implement
a relatively small subset of that functionality based around the needs
of LLVM, Clang, the Clang driver, etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171285 91177308-0d34-0410-b5e6-96231b3b80d8
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171253 91177308-0d34-0410-b5e6-96231b3b80d8
constant folding calls. Add the initial tests for this which show that
now instsimplify can simplify blindingly obvious code patterns expressed
with both intrinsics and library calls.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171194 91177308-0d34-0410-b5e6-96231b3b80d8
are nice and decomposed so that we can simplify synthesized calls as
easily as actually call instructions. The internal utility still has the
same behavior, it just now operates on a more generic interface so that
I can extend the set of call simplifications that instsimplify knows
about.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171189 91177308-0d34-0410-b5e6-96231b3b80d8
re-use that for SlotIndexes. This way other users who want half-open
semantics can share the implementation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171158 91177308-0d34-0410-b5e6-96231b3b80d8
information doesn't return an addend for Rel relocations. Go ahead
and use this information to fix relocation handling inside dwarfdump
for 32-bit ELF REL.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171126 91177308-0d34-0410-b5e6-96231b3b80d8
As with the prefetch intrinsic to which it maps, simply have dcbt
marked as reading from and writing to its arguments instead of having
unmodeled side effects. While this might cause unwanted code motion
(because aliasing checks don't really capture cache-line sharing),
it is more important that prefetches in unrolled loops don't block
the scheduler from rearranging the unrolled loop body.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171073 91177308-0d34-0410-b5e6-96231b3b80d8
These are now generally used for all diagnostics from the backend, not just
for inline assembly, so this drops the "InlineAsm" from the names. No
functional change. (I've left aliases for the old names but only for long
enough to let me switch over clang to use the new ones.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171047 91177308-0d34-0410-b5e6-96231b3b80d8
When the backend is used from clang, it should produce proper diagnostics
instead of just printing messages to errs(). Other clients may also want to
register their own error handlers with the LLVMContext, and the same handler
should work for warnings in the same way as the existing emitError methods.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171041 91177308-0d34-0410-b5e6-96231b3b80d8
the cost of arithmetic functions. We now assume that the cost of arithmetic
operations that are marked as Legal or Promote is low, but ops that are
marked as custom are higher.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171002 91177308-0d34-0410-b5e6-96231b3b80d8
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 inform
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.
The main difference from the previous patch is that it doesn't use
InMemoryStruct. It is extremely dangerous: if the endians match it returns
a pointer to the file buffer, if not, it returns a pointer to an internal buffer
that is overwritten in the next API call.
We should change all of this code to use
support::detail::packed_endian_specific_integral like ELF, but since these
functions only handle strings, they work with big and little endian machines
as is.
I have tested this by installing ubuntu 12.10 ppc on qemu, that is why it took
so long :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170838 91177308-0d34-0410-b5e6-96231b3b80d8
Instructions that are inserted in a basic block can still be decorated
with addOperand(MO).
Make the two-argument addOperand() function contain the actual
implementation. This function will now always have a valid MF reference
that it can use for memory allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170798 91177308-0d34-0410-b5e6-96231b3b80d8
This function is often used to decorate dangling instructions, so a
context reference is required to allocate memory for the operands.
Also add a corresponding MachineInstrBuilder method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170797 91177308-0d34-0410-b5e6-96231b3b80d8
Rename the AttributeImpl* from Attrs to pImpl to be consistent with other code.
Add comments where none were before. Or doxygen-ify other comments.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170767 91177308-0d34-0410-b5e6-96231b3b80d8
This is supposed to be a mechanical change with no functional effects.
InstrEmitter can generate all types of MachineOperands which revealed
that MachineInstrBuilder was missing a few methods, added by this patch.
Besides providing a context pointer to MI::addOperand(),
MachineInstrBuilder seems like a better fit for this code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170712 91177308-0d34-0410-b5e6-96231b3b80d8
Similarly inlining of the function is inhibited, if that would duplicate the call (in particular inlining is still allowed when there is only one callsite and the function has internal linkage).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170704 91177308-0d34-0410-b5e6-96231b3b80d8
behavior and violates the !range constraints we put on loads of this enum.
Found by clang -fsanitize=enum.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170653 91177308-0d34-0410-b5e6-96231b3b80d8
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
for a wider range of GOT entries that can hold thread-relative offsets.
This matches the behavior of GCC, which was not documented in the PPC64 TLS
ABI. The ABI will be updated with the new code sequence.
Former sequence:
ld 9,x@got@tprel(2)
add 9,9,x@tls
New sequence:
addis 9,2,x@got@tprel@ha
ld 9,x@got@tprel@l(9)
add 9,9,x@tls
Note that a linker optimization exists to transform the new sequence into
the shorter sequence when appropriate, by replacing the addis with a nop
and modifying the base register and relocation type of the ld.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170209 91177308-0d34-0410-b5e6-96231b3b80d8
