Build attribute sections can now be read if they exist via ELFObjectFile, and
the llvm-readobj tool has been extended with an option to dump this information
if requested. Regression tests are also included which exercise these features.
Also update the docs with a fixed ARM ABI link and a new link to the Addenda
which provides the build attributes specification.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181009 91177308-0d34-0410-b5e6-96231b3b80d8
Also add a check for llvm.used in the verifier and simplify clients now that
they can assume they have a ConstantArray.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180019 91177308-0d34-0410-b5e6-96231b3b80d8
This option expands shown relocations from single line to a dictionary
format:
Relocation {
Offset: 0x4
Type: R_386_32 (1)
Symbol: sym
Info: 0x0
}
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179359 91177308-0d34-0410-b5e6-96231b3b80d8
Add support for the COFF relocation types IMAGE_REL_I386_DIR32NB and
IMAGE_REL_AMD64_ADDR32NB for 32- and 64-bit respectively. These are
similar to normal 4-byte relocations except that they do not include
the base address of the image.
Image-relative relocations are used for debug information (32-bit) and
SEH unwind tables (64-bit).
A new MCSymbolRef variant called 'VK_COFF_IMGREL32' is introduced to
specify such relocations. For AT&T assembly, this variant can be accessed
using the symbol suffix '@imgrel'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179240 91177308-0d34-0410-b5e6-96231b3b80d8
Nobody says "the developer's list" or "commits archive"; they always say
"llvmdev" or "llvm-commits". It makes sense for our documentation to
at least make that association explicitly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178425 91177308-0d34-0410-b5e6-96231b3b80d8
std::lower_bound is the canonical "binary search" in the STL
(std::binary_search generally is not what you want). The name actually
makes a lot of sense (and also has a beautiful symmetry with the
std::upper_bound algorithm). The name is nonetheless non-obvious.
Also, remove mention of "radix search". It's not even clear how that
would work in the context of a sorted vector. AFAIK "radix search" only
makes sense when you have a trie-like data structure.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178376 91177308-0d34-0410-b5e6-96231b3b80d8
DAG arguments can optionally be named:
(dag node, node:$name)
With this change, the node is also optional:
(dag node, node:$name, $name)
The missing node is treated as an UnsetInit, so the above is equivalent
to:
(dag node, node:$name, ?:$name)
This syntax is useful in output patterns where we currently require the
types of variables to be repeated:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr i32:$b, i32:$c)>;
This is preferable:
def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177843 91177308-0d34-0410-b5e6-96231b3b80d8
Also update the documentation since Sparc is the nicest backend, and
used as an example in WritingAnLLVMBackend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177835 91177308-0d34-0410-b5e6-96231b3b80d8
The new wording cannot be construed as suggesting the use of
SmallVectorImpl<T> as e.g. a class member (just because the class
happens to be in an interface).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177778 91177308-0d34-0410-b5e6-96231b3b80d8
of complex instruction operands (e.g. address modes).
Currently, if a Pat pattern creates an instruction that has a complex
operand (i.e. one that consists of multiple sub-operands at the MI
level), this operand must match a ComplexPattern DAG pattern with the
correct number of output operands.
This commit extends TableGen to alternatively allow match a complex
operands against multiple separate operands at the DAG level.
This allows using Pat patterns to match pre-increment nodes like
pre_store (which must have separate operands at the DAG level) onto
an instruction pattern that uses a multi-operand memory operand,
like the following example on PowerPC (will be committed as a
follow-on patch):
def STWU : DForm_1<37, (outs ptr_rc:$ea_res), (ins GPRC:$rS, memri:$dst),
"stwu $rS, $dst", LdStStoreUpd, []>,
RegConstraint<"$dst.reg = $ea_res">, NoEncode<"$ea_res">;
def : Pat<(pre_store GPRC:$rS, ptr_rc:$ptrreg, iaddroff:$ptroff),
(STWU GPRC:$rS, iaddroff:$ptroff, ptr_rc:$ptrreg)>;
Here, the pair of "ptroff" and "ptrreg" operands is matched onto the
complex operand "dst" of class "memri" in the "STWU" instruction.
Approved by Jakob Stoklund Olesen.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@177428 91177308-0d34-0410-b5e6-96231b3b80d8
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@176075 91177308-0d34-0410-b5e6-96231b3b80d8
The 'nobuiltin' attribute is applied to call sites to indicate that LLVM should
not treat the callee function as a built-in function. I.e., it shouldn't try to
replace that function with different code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175835 91177308-0d34-0410-b5e6-96231b3b80d8
This is based on Bill Wendling's email. No additional content has been added,
but now there's a place for Attributes to capture future information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174961 91177308-0d34-0410-b5e6-96231b3b80d8
This updates the current references to links that work for me.
In the future, we should update the list of references itself to provide
information on newer architecture variants.
Thanks to Sean Silva for pointing out that the current links were broken!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174739 91177308-0d34-0410-b5e6-96231b3b80d8
Attribute groups are of the form:
#0 = attributes { noinline "no-sse" "cpu"="cortex-a8" alignstack=4 }
Target-dependent attributes are represented as strings. Attributes can have
optional values associated with them. E.g., the "cpu" attribute has the value
"cortex-a8".
Target-independent attributes are listed as enums inside the attribute classes.
Multiple attribute groups can be referenced by the same object. In that case,
the attributes are merged together.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174493 91177308-0d34-0410-b5e6-96231b3b80d8
definition
Current practice is not to use 'inline' in:
class Foo {
public:
inline void bar() {
// ...
}
};
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174317 91177308-0d34-0410-b5e6-96231b3b80d8
Makefile.config.
This is implied at the bottom of the help text of configure (besides
CC/CXX/LDFLAGS, already passed to Makefile.config).
For backward compatibility, the values of CFLAGS and CXXFLAGS defaults
to empty, overriding the default values provided by autoconf (for
example, '-g -O2' when CC=gcc').
$(CPP) is not used by our makefiles. Therefore, the value of CPP is
not passed to Makefile.config, despite beeing mentioned by 'configure
--help'.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174313 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174269 91177308-0d34-0410-b5e6-96231b3b80d8
My "excuse" for not refactoring the grammar here is to not diverge too
far from the grammar in the comments of TGParser.cpp, since I'm not
taking on the quest of majorly refactoring TGParser.cpp at the moment.
One benefit of doing this is that Ideas for refactoring and clarifying
the grammar in this document should translate almost immediately to
beneficial refactorings that can be made to TGParser.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174144 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds support for AArch64 (ARM's 64-bit architecture) to
LLVM in the "experimental" category. Currently, it won't be built
unless requested explicitly.
This initial commit should have support for:
+ Assembly of all scalar (i.e. non-NEON, non-Crypto) instructions
(except the late addition CRC instructions).
+ CodeGen features required for C++03 and C99.
+ Compilation for the "small" memory model: code+static data <
4GB.
+ Absolute and position-independent code.
+ GNU-style (i.e. "__thread") TLS.
+ Debugging information.
The principal omission, currently, is performance tuning.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174054 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173974 91177308-0d34-0410-b5e6-96231b3b80d8
Boilerplate is often the hardest part of getting started with these
kinds of things, so throw them a bone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173969 91177308-0d34-0410-b5e6-96231b3b80d8
custom git script called git-svnup which handles all of the work of
using the git-mirrors/keeping the git-svn numbers in sync.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173472 91177308-0d34-0410-b5e6-96231b3b80d8
This adds an !add(a, b) operator to tablegen; this will be used
to cleanup the PPC register definitions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173445 91177308-0d34-0410-b5e6-96231b3b80d8
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.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173231 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173230 91177308-0d34-0410-b5e6-96231b3b80d8
This change also removes a bunch of boilerplate and stuffing which made
it unnecessarily hard to navigate and see the comparatively miniscule
actual content that was added to this document during the 3.2
development period (or maybe even sticking around from earlier
releases...).
The new organization (a flat list) optimizes for making it easy for
people who know about changes to add them to the document. It's
completely trivial for anyone with basic knowledge of LLVM to come in
later (such as when preparing for the actual release) and cluster any
changes into logical groups. However, I have left some comments
indicating how to add larger descriptions, if someone is feeling
adventurous ;)
Hopefully this organization will highlight how little effort is being
put into producing accurate, high-quality release notes, prompting a
corresponding improvement for the 3.3 release.
I have preserved the changes to this document that are not present
in the 3.2 release notes. There were only two... I'm pretty sure we've
been busier than that... (version control shows +213347/-173656 raw
lines just in the LLVM repo since the 3.2 release).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172954 91177308-0d34-0410-b5e6-96231b3b80d8
This brings back {Ctrl,Cmd}-f'ability, and makes some really bad
organizational choices easier to see (and therefore fix).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172949 91177308-0d34-0410-b5e6-96231b3b80d8
grep is now only mentioned once in a sentence that explicitly says it's
deprecated. For FileCheck, there's no reason to repeat part of the
documentation that exists in CommandGuide/FileCheck.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172835 91177308-0d34-0410-b5e6-96231b3b80d8
- This code is dead, and the "right" way to get this support is to use the
platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM
linker.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172749 91177308-0d34-0410-b5e6-96231b3b80d8
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.
This fixes PR14891 as a special case.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172162 91177308-0d34-0410-b5e6-96231b3b80d8
against the developer policy to include this sort of thing as SVN blame
already captures this in a far more fine-grained way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172109 91177308-0d34-0410-b5e6-96231b3b80d8
It's not just def's but actually a limited subset of Object's that are
allowed inside a multiclass.
Spotted by Joel Jones.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171935 91177308-0d34-0410-b5e6-96231b3b80d8
I actually made a think-o when writing this FIXME since I wrote LangRef
but it should actually have said WritingAnLLVMBackend.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171293 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
This is a pretty lengthy document, so put the table of contents in your
face so that it's easier to scope out the content.
This document is a mess currently and needs to be
refactored/revised/split-up.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170646 91177308-0d34-0410-b5e6-96231b3b80d8
For whatever reason the usage of '^^^' and '---' adornments were
reversed compared to the "canonical" style of the LLVM docs (which is
currently "the style used in SphinxQuickstartTemplate.rst"). This change
doesn't affect the document structure at all, I'm just doing it for
trivial stylistic consistency (the document content is *much* more
important---thanks Nadav for writing this up!).
Also, trim the adornments to be the same length as the section names.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170638 91177308-0d34-0410-b5e6-96231b3b80d8
Building Vectorizers.rst produces a few warnings of the form:
WARNING: Title underline too short.
Fixed by adding the extra needed dashes under the title.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170582 91177308-0d34-0410-b5e6-96231b3b80d8
will look a bit different when we have time to get it ready to turn on,
and we won't likely need this reminder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170195 91177308-0d34-0410-b5e6-96231b3b80d8
If anyone has better highlights (I'm obviously biased by the things that
I'm excited about) jump in and add them!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170194 91177308-0d34-0410-b5e6-96231b3b80d8
Replaces old Pentium 4 documentation link with generic current documentation link.
Patch by Kevin Schoedel.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@170144 91177308-0d34-0410-b5e6-96231b3b80d8
Since now we have an autogenerated TOC, a manually written table of all passes
was removed.
Patch by Anthony Mykhailenko with small fixes by me.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169867 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169596 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry for the massive commit, but I just wanted to knock this one down
and it is really straightforward.
There are still a couple trivial (i.e. not related to the content)
things left to fix:
- Use of raw HTML links where :doc:`...` and :ref:`...` could be used
instead. If you are a newbie and want to help fix this it would make
for some good bite-sized patches; more experienced developers should
be focusing on adding new content (to this tutorial or elsewhere, but
please _do not_ waste your time on formatting when there is such dire
need for documentation (see docs/SphinxQuickstartTemplate.rst to get
started writing)).
- Highlighting of the kaleidoscope code blocks (currently left as bare
`::`). I will be working on writing a custom Pygments highlighter for
this, mostly as training for maintaining the `llvm` code-block's lexer
in-tree. I want to do this because I am extremely unhappy with how it
just "gives up" on the slightest deviation from the expected syntax
and leaves the whole code-block un-highlighted.
More generally I am looking at writing some Sphinx extensions and
keeping them in-tree as well, to support common use cases that
currently have no good solution (like "monospace text inside a link").
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169343 91177308-0d34-0410-b5e6-96231b3b80d8
