Function attributes are the future! So just query whether we want to realign the
stack directly from the function instead of through a random target options
structure.

llvm-svn: 187618

There's no need to specify a flag to omit frame pointer elimination on non-leaf
nodes...(Honestly, I can't parse that option out.) Use the function attribute
stuff instead.

llvm-svn: 187093

The main observation is that we never need both the filesize and the map size.
When mapping a slice of a file, it doesn't make sense to request a null
terminator and that would be the only case where the filesize would be used.

There are other cleanups that should be done in this area:

* A client should not have to pass the size (even an explicit -1) to say if
  it wants a null terminator or not, so we should probably swap the argument
  order.
* The default should be to not require a null terminator. Very few clients
  require this, but many end up asking for it just because it is the default.

llvm-svn: 186984

 Use the function attributes to pass along the stack protector buffer size.

 Now that we have robust function attributes, don't use a command line option to
 specify the stack protecto buffer size.

llvm-svn: 186863

  http://lab.llvm.org:8013/builders/clang-x86_64-darwin11-nobootstrap-RAincremental/builds/4328

Original commit log:
  Use the function attributes to pass along the stack protector buffer
  size.

llvm-svn: 186234

Now that we have robust function attributes, don't use a command line option to
specify the stack protecto buffer size.

llvm-svn: 186217

This is dead code since PIC16 was removed in 2010. The result was an odd mix,
where some parts would carefully pass it along and others would assert it was
zero (most of the object streamer for example).

llvm-svn: 185436

Someone may want to do something crazy, like replace these objects if they
change or something.

No functionality change intended.

llvm-svn: 184175

llvm-svn: 183840

This is preparation for replacing Path.h with PathV2.h.

llvm-svn: 183782

No functionality change.

llvm-svn: 183759

llvm-svn: 183669

Not only does this break encapsulation, it's gross.

llvm-svn: 182876

llvm-svn: 182680

Differential Revision: http://llvm-reviews.chandlerc.com/D598

llvm-svn: 179725

llvm-svn: 174115

isa<> and dyn_cast<>. In several places, code is already hacking around
the absence of this, and there seem to be several interfaces that might
be lifted and/or devirtualized using this.

This change was based on a discussion with Jim Grosbach about how best
to handle testing for specific MCStreamer subclasses. He said that this
was the correct end state, and everything else was too hacky so
I decided to just make it so.

No functionality should be changed here, this is just threading the kind
through all the constructors and setting up the classof overloads.

llvm-svn: 174113

The aim of this patch is to fix the following piece of code in the
platform-independent AsmParser:

void AsmParser::CheckForValidSection() {
  if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
    TokError("expected section directive before assembly directive");
    Out.SwitchSection(Ctx.getMachOSection(
                        "__TEXT", "__text",
                        MCSectionMachO::S_ATTR_PURE_INSTRUCTIONS,
                        0, SectionKind::getText()));
  }
}

This was added for the "-n" option of llvm-mc.

The proposed fix adds another virtual method to MCStreamer, called
InitToTextSection. Conceptually, it's similar to the existing
InitSections which initializes all common sections and switches to
text. The new method is implemented by each platform streamer in a way
that it sees fit. So AsmParser can now do this:

void AsmParser::CheckForValidSection() {
  if (!ParsingInlineAsm && !getStreamer().getCurrentSection()) {
    TokError("expected section directive before assembly directive");
    Out.InitToTextSection();
  }
}

Which is much more reasonable.

llvm-svn: 172450

bundling. The document describing this feature and the implementation has also
been updated:

https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm

llvm-svn: 171797

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.

llvm-svn: 171366

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056754.html

The proposal and implementation are fully documented here:
https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/aligned-bundling-support-in-llvm

Tests will follow shortly.

llvm-svn: 170718

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.html
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01273.html 

llvm-svn: 170279

llvm-svn: 169812

Again, tools are trickier to pick the main module header for than
library source files. I've started to follow the pattern of using
LLVMContext.h when it is included as a stub for program source files.

llvm-svn: 169252

This is a temporary hack until Bill's project to record command line options
in the LLVM IR is ready. Clang currently sets a default CPU but that isn't
recorded anywhere and it doesn't get used in the final LTO compilation.

llvm-svn: 165809

llvm-svn: 165403

llvm-svn: 163258

PR9673

llvm-svn: 162284

make it more consistent with its intended semantics.

The `linker_private_weak_def_auto' linkage type was meant to automatically hide
globals which never had their addresses taken. It has nothing to do with the
`linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
among other things.

The intended semantic is more like the `linkonce_odr' linkage type.

Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
changing the semantics so that it produces the correct output for the linker.

Note: The old linkage name `linker_private_weak_def_auto' will still parse but
is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
<rdar://problem/11754934>

llvm-svn: 162114

llvm-svn: 161529

llvm-svn: 161356

When the command line target options were removed from the LLVM libraries, LTO
lost its ability to specify things like `-disable-fp-elim'. Add this back by
adding the command line variables to the `lto' project.
<rdar://problem/12038729>

llvm-svn: 161353

llvm-svn: 159028

llvm-svn: 156606

llvm-svn: 153928

reflected in the LLVM IR (as a declare or something), then treat it like a data
object.

N.B. This isn't 100% correct. The ASM parser should supply more information so
that we know what type of object it is, and what attributes it should have.

llvm-svn: 153870

definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.

llvm-svn: 153859

llvm-svn: 153807

  into the function.
* Reorder some header files.

llvm-svn: 153783

Module-level ASM may contain definitions of functions and globals. However, we
were not telling the linker that these globals had definitions. As far as it was
concerned, they were just declarations.

Attempt to resolve this by inserting module-level ASM functions and globals into
the '_symbol' set so that the linker will know that they have values.

This gets us further towards our goal of compiling LLVM, but it still has
problems when linking libLTO.dylib because of the `-dead_strip' flag that's
passed to the linker.

<rdar://problem/11124216>

llvm-svn: 153638