llvm-svn: 170902

llvm-svn: 170901

This is very mechanical, no functionality change. Preparation for PR14667.

llvm-svn: 170898

170318).

llvm-svn: 170886

llvm-svn: 170883

llvm-svn: 170842

llvm-svn: 170841

llvm-svn: 170840

Now that we don't merge section and segment names, we don't need to skip the
segment name to get to the section name.

llvm-svn: 170839

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 :-)

llvm-svn: 170838

llvm-svn: 170836

llvm-svn: 170831

llvm-svn: 170830

and not the return type, which is void. A number of test
cases fail after adding the assertion in TTImpl.

llvm-svn: 170828

llvm-svn: 170823

llvm-svn: 170822

Hopefully these benchmarks will be updated in the future, so avoid
hardcoding image dimensions.

llvm-svn: 170819

Tell the image to be its natural size.

llvm-svn: 170816

memory bound checks.  Before the fix we were able to vectorize this loop from
the Livermore Loops benchmark:

for ( k=1 ; k<n ; k++ )
  x[k] = x[k-1] + y[k];

llvm-svn: 170811

llvm-svn: 170810

Please squawk if you find this appalling or otherwise don't like it.

llvm-svn: 170803

llvm-svn: 170799

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.

llvm-svn: 170798

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.

llvm-svn: 170797

llvm-svn: 170796

llvm-svn: 170795

llvm-svn: 170794

for code that wasn't even in bundling mode.

llvm-svn: 170793

llvm-svn: 170792

llvm-svn: 170791

Add links in the intro paragraph.
Add table of contents.

llvm-svn: 170790

llvm-svn: 170776

llvm-svn: 170771

into the DwarfUnits class.

llvm-svn: 170770

Hopefully nobody has linked to it yet...

OK'd by Nadav.

llvm-svn: 170768

Rename the AttributeImpl* from Attrs to pImpl to be consistent with other code.
Add comments where none were before. Or doxygen-ify other comments.

llvm-svn: 170767

llvm-svn: 170766

This reverts r170694.  The operations can be represented in IR without
adding any new intrinsics.

llvm-svn: 170765

Before if-conversion we could check if a value is loop invariant
if it was declared inside the basic block. Now that loops have
multiple blocks this check is incorrect.

This fixes External/SPEC/CINT95/099_go/099_go

llvm-svn: 170756

are more expensive than the non-flag setting variant. Teach thumb2 size
reduction pass to avoid generating them unless we are optimizing for size.

rdar://12892707

llvm-svn: 170728