GlobalVariable about LLVM's assumptions vis-a-vis Global Variable
initial values and Global Variable initializers.

This is in preparation for adding the new keyword
externally_initialized.

Specifically, the patch explains how LLVM optimizes global initializers
by assumign that global variables defined within the module are not
modified from their initial values before the start of the global
initializer.

llvm-svn: 174269

Fixed a mistake in my previous commit where I changed the wording slightly and forgot to undo the change after changing my mind and deciding to only commit the style changes.

llvm-svn: 174041

section Global Variable so that the style matches the other keywords in
said section.

llvm-svn: 174040

llvm-svn: 174007

prevent an llvm developer from mistakenly thinking that just because the
intrinsic has volatile flags that volatile operations can be converted
to or folded into them.

Platforms may rely on volatile loads and stores of natively supported
data width to be executed as single instruction. When compiling
C, this expectation likely holds for l-values of volatile primitive
types with native hardware support, but not necessarily for aggregate
types. The frontend upholds these expectations, which are not
specified in the IR.

llvm-svn: 173974

correspond to the code.

Patch by Stephen McGruer.

llvm-svn: 173914

llvm-svn: 173845

Patch by David Waggoner

llvm-svn: 173571

llvm-svn: 173298

The requirements of the strong heuristic are:

* A Protector is required for functions which contain an array, regardless of
  type or length.

* A Protector is required for functions which contain a structure/union which
  contains an array, regardless of type or length.  Note, there is no limit to
  the depth of nesting.

* A protector is required when the address of a local variable (i.e., stack
  based variable) is exposed. (E.g., such as through a local whose address is
  taken as part of the RHS of an assignment or a local whose address is taken as
  part of a function argument.)

llvm-svn: 173231

SSPStrong applies a heuristic to insert stack protectors in these situations:

* A Protector is required for functions which contain an array, regardless of
  type or length.

* A Protector is required for functions which contain a structure/union which
  contains an array, regardless of type or length.  Note, there is no limit to
  the depth of nesting.

* A protector is required when the address of a local variable (i.e., stack
  based variable) is exposed. (E.g., such as through a local whose address is
  taken as part of the RHS of an assignment or a local whose address is taken as
  part of a function argument.)

This patch implements the SSPString attribute to be equivalent to
SSPRequired. This will change in a subsequent patch.

llvm-svn: 173230

llvm-svn: 172917

 - Also, fixup syntax errors in LangRef and missing newline in the MCAsmStreamer.

llvm-svn: 172837

llvm-svn: 172741

llvm-svn: 172681

ambiguous term 'legal'.

Suggested by Andrew Booker. Thanks Andrew!

llvm-svn: 172680

Reported on IRC by _savage

llvm-svn: 172677

llvm-svn: 172659

 - Also, update the LangRef documentation on module flags to match the
   implementation.

llvm-svn: 172498

Add a new attribute, 'noduplicate'. If a function contains a noduplicate call, the call cannot be duplicated - Jump threading, loop unrolling, loop unswitching, and loop rotation are inhibited if they would duplicate the call.

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

llvm-svn: 170704

llvm-svn: 169704

NOTE: If you have any patches in the works that modify LangRef, you will
need to rewrite the changes to LangRef.html to their equivalents in
LangRef.rst. If you need assistance feel free to contact me.

Since LangRef is mission-critical for the project and "normative", I
have taken extra care to ensure that no content was lost or altered in
the conversion. The content was converted with a tool called `pandoc`,
so there is no chance for a human error like accidentally forgetting a
sentence or whatever. After the initial conversion by `pandoc`, only
changes to the markup were done.

This is just the most literal conversion of the HTML document as
possible. It might be worth exploring some way to chop up this massive
document into separate pages, e.g. something like
`docs/LangRef/Instructions.rst`, `docs/LangRef/Intrinsics.rst`, etc.
with `docs/LangRef.rst` being an "intro/navigation page" of sorts. On
the other hand, that loses the ability to {Ctrl,Cmd}-F for a given term
right from your browser.

IMO, I think our stylesheet needs some work because I find it hard to
tell what level of nesting some of the headings are at (e.g. "is this a
new section or is it a subsection?"). The issue is present on other
pages, but the sheer size and deep section structure of LangRef really
brings this issue out. If there are any web designers out there in the
community it would be awesome if you tried to come up with something
nicer.

llvm-svn: 169596