The official specifications state the name to be ARMNT (as per the Microsoft
Portable Executable and Common Object Format Specification v8.3).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203530 91177308-0d34-0410-b5e6-96231b3b80d8
The grammar for LLVM IR is not well specified in any document but seems
to obey the following rules:
- Attributes which have parenthesized arguments are never preceded by
commas. This form of attribute is the only one which ever has
optional arguments. However, not all of these attributes support
optional arguments: 'thread_local' supports an optional argument but
'addrspace' does not. Interestingly, 'addrspace' is documented as
being a "qualifier". What constitutes a qualifier? I cannot find a
definition.
- Some attributes use a space between the keyword and the value.
Examples of this form are 'align' and 'section'. These are always
preceded by a comma.
- Otherwise, the attribute has no argument. These attributes do not
have a preceding comma.
Sometimes an attribute goes before the instruction, between the
instruction and it's type, or after it's type. 'atomicrmw' has
'volatile' between the instruction and the type while 'call' has 'tail'
preceding the instruction.
With all this in mind, it seems most consistent for 'inalloca' on an
'inalloca' instruction to occur before between the instruction and the
type. Unlike the current formulation, there would be no preceding
comma. The combination 'alloca inalloca' doesn't look particularly
appetizing, perhaps a better spelling of 'inalloca' is down the road.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203376 91177308-0d34-0410-b5e6-96231b3b80d8
The following changes have been applied:
- Removed 'align 4'. We can simplify this away, as it does not provide useful
information in the example.
- Use named instructions instead of '%0'. This is nicer, but more importantly
this makes the IR valid. Before we had two assignments to %0 in a single
example.
- Add a missing branch instruction to make the loop structure clear.
- Move one access into outer.for.body to make it not look that empty.
- The statments that are only in the outer loop body should not reference the
inner loop metadata, but only the outer loop. Only statements in both loops
should reference both surrounding loops.
- Rename the array indexes to make them all independent. Before there were
identical array indexes in the inner and the outer loop. We want to
avoid this special case as it may lead to confusion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202973 91177308-0d34-0410-b5e6-96231b3b80d8
The distinction between "identified" and "literal" struct types is fully
documented in a later section.
Patch by Philip Reames!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202927 91177308-0d34-0410-b5e6-96231b3b80d8
directly care about the Value class (it is templated so that the key can
be any arbitrary Value subclass), it is in fact concretely tied to the
Value class through the ValueHandle's CallbackVH interface which relies
on the key type being some Value subclass to establish the value handle
chain.
Ironically, the unittest is already in the right library.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202824 91177308-0d34-0410-b5e6-96231b3b80d8
It's easy to copy unintentionally when using 'auto', particularly inside
range-based for loops. Best practise is to use 'const&' unless there's
a good reason not to.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202729 91177308-0d34-0410-b5e6-96231b3b80d8
The current coding standards restrict the use of struct to PODs, but no
one has been following them. This patch updates the standards to
clarify when structs are dangerous and describe common practice in LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202728 91177308-0d34-0410-b5e6-96231b3b80d8
facilitate the nice formatting of lambdas passed there. Suggested by
Chris during review of my lambda additions, and something I strongly
agree with.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202622 91177308-0d34-0410-b5e6-96231b3b80d8
about a few constructs in C++11 that are worth starting off in
a consistent manner within the codebase.
This will be matched with a change to clang-format's LLVM style which
will switch the options to support C++11 and use these conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202620 91177308-0d34-0410-b5e6-96231b3b80d8
The docs now build cleanly. Yay!
The following warnings were fixed:
/home/sean/pg/llvm/llvm/docs/HowToReleaseLLVM.rst:364: WARNING: Enumerated list ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/InAlloca.rst:: WARNING: document isn't included in any toctree
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.
Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.
Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:185: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:565: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:567: WARNING: Block quote ends without a blank line; unexpected unindent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202603 91177308-0d34-0410-b5e6-96231b3b80d8
The switch has been thrown. While I'm still watching for any failures or
problems with this, the documentation can go ahead and move forward.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202566 91177308-0d34-0410-b5e6-96231b3b80d8
bots when using the standard library facilities. The missing pieces here
aren't always in useful discreet chunks.
Fortunately, the missing pieces are few and far between, and we can
emulate most of them in our headers as needed.
Based on feedback from Lang and Dave.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202548 91177308-0d34-0410-b5e6-96231b3b80d8
A lot of this is writing down common knowledge and things often
communicated on mailing lists and in discussions. It could live in the
Programmer's Manual alternatively, but that felt slightly less
well-fitting.
It also includes (and was motivated by) the section on the relevant
language standards for LLVM and the specific features that will be
enabled with the switch to C++11.
With this, all of the documentation for the C++11 switch is, I think, in
place. I plan to flip the switch RSN. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202497 91177308-0d34-0410-b5e6-96231b3b80d8
standards.
It claims the document intentionally doesn't give fixed standards for
brace placement or spacing, and then the document goes on to do
precisely that in several places. Instead, try to highlight that even
these rules are simply *guidance* which may be trumped by some other
circumstance or the local conventions of code.
I'm not trying to change the thrust of this part of the document, and if
folks think this does so, I'm happy to re-wordsmith it. I just don't
want it to be so self-contradicting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202495 91177308-0d34-0410-b5e6-96231b3b80d8
a more modern host C++ toolchain for Linux distros where folks sometimes
don't have a good option to get one as part of their system.
This is a first cut, so feedback, testing, and suggestions are very,
very welcom. This is one of the last real documentation changes that was
specifically requested prior to switching LLVM and Clang to build in
C++11 mode by default.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202486 91177308-0d34-0410-b5e6-96231b3b80d8
seems unlikely to be added. It also doesn't seem like it should be part
of the build system at all (consider out-of-tree builds).
We should probably add nice, easy tool for this that works both for svn
client trees and git-svn client trees, but it probably won't be spelled
"make update".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202430 91177308-0d34-0410-b5e6-96231b3b80d8
toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]
Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.
The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202375 91177308-0d34-0410-b5e6-96231b3b80d8
bits of software and to use a modern GCC version.
The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).
The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.
I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
regenerating configure scripts).
Also we need to mention that there are multiple options for build
systems, and the differences.
Also we should mention Windows.
Also probably other stuff I'm forgetting.
I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202373 91177308-0d34-0410-b5e6-96231b3b80d8
actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202371 91177308-0d34-0410-b5e6-96231b3b80d8
getting started guide.
Some highlights:
- I heard there was this Clang compiler that you could use for your
host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.
There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202370 91177308-0d34-0410-b5e6-96231b3b80d8
The original text is very terse, so I've expanded on it.
Specifically, in the original text:
* "The selector value is a positive number if the exception matched a
type info" -- It wasn't clear that this meant "if the exception
matched a 'catch' clause".
* "If nothing is matched, the behavior of the program is
`undefined`_." -- It's actually implementation-defined in C++
rather than undefined, as the new text explains.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202209 91177308-0d34-0410-b5e6-96231b3b80d8
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201836 91177308-0d34-0410-b5e6-96231b3b80d8
Some references to llvm-gcc were so crusty that I wasn't sure how to
proceed and so I've left them intact.
I also slipped in a quick peephole fix to use a :doc: link instead of
raw HTML link.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201619 91177308-0d34-0410-b5e6-96231b3b80d8
From a cursory look it seems like all the described commandline options
and such apply to clang just fine, but I'd appreciate a second opinion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201616 91177308-0d34-0410-b5e6-96231b3b80d8
Introducing llvm-profdata, a tool for merging profile data generated by
PGO instrumentation in clang.
- The name indicates a file extension of <name>.profdata. Eventually
profile data output by clang should be changed to that extension.
- llvm-profdata merges two profiles. However, the name is more general,
since it will likely pick up more tasks (such as summarizing a single
profile).
- llvm-profdata parses the current text-based format, but will be
updated once we settle on a binary format.
<rdar://problem/15949645>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201535 91177308-0d34-0410-b5e6-96231b3b80d8
Fun fact: looking at the TableGen code (around TGParser.cpp:1166), the
only difference in handling is that adjacent regular string literals are
concatenated in the parser.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201035 91177308-0d34-0410-b5e6-96231b3b80d8
They're called code fragments, but they are really multiline string
literals. Just spotted this usage in a patch by Aaron using "code
fragments" for holding documentation text. I remember someone bemoaning
the lack of multiline string literals in TableGen, so I'm explicitly
documenting that code fragments are multiline string literals.
Let it be known that any use case needing multiline string literals in
TableGen (such as descriptions of options, or whatnot) can use use
code fragments (instead of C-style string concatenation or exceedingly
long lines). E.g.
class Bar<int n>;
class Baz<int n>;
class Doc<string desc> {
string Desc = desc;
}
def Foo : Bar<1>, Baz<3>, Doc<[{
This Foo is a Bar, and also a Baz. It can take 3 values:
* Qux
* Quux
* Quuux
}]>;
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201033 91177308-0d34-0410-b5e6-96231b3b80d8
LowerExpectIntrinsic previously only understood the idiom of an expect
intrinsic followed by a comparison with zero. For llvm.expect.i1, the
comparison would be stripped by the early-cse pass.
Patch by Daniel Micay.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200664 91177308-0d34-0410-b5e6-96231b3b80d8
This changes the PrologueEpilogInserter and LocalStackSlotAllocation passes to
follow the extended stack layout rules for sspstrong and sspreq.
The sspstrong layout rules are:
1. Large arrays and structures containing large arrays (>= ssp-buffer-size)
are closest to the stack protector.
2. Small arrays and structures containing small arrays (< ssp-buffer-size) are
2nd closest to the protector.
3. Variables that have had their address taken are 3rd closest to the
protector.
Differential Revision: http://llvm-reviews.chandlerc.com/D2546
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200601 91177308-0d34-0410-b5e6-96231b3b80d8
Calls with inalloca are lowered by skipping all stores for arguments
passed in memory and the initial stack adjustment to allocate argument
memory.
Now the frontend is responsible for the memory layout, and the backend
doesn't have to do any work. As a result these changes are pretty
minimal.
Reviewers: echristo
Differential Revision: http://llvm-reviews.chandlerc.com/D2637
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200596 91177308-0d34-0410-b5e6-96231b3b80d8
MSVC always places the 'this' parameter for a method first. The
implicit 'sret' pointer for methods always comes second. We already
implement this for __thiscall by putting sret parameters on the stack,
but __cdecl methods require putting both parameters on the stack in
opposite order.
Using a special calling convention allows frontends to keep the sret
parameter first, which avoids breaking lots of assumptions in LLVM and
Clang.
Fixes PR15768 with the corresponding change in Clang.
Reviewers: ributzka, majnemer
Differential Revision: http://llvm-reviews.chandlerc.com/D2663
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200561 91177308-0d34-0410-b5e6-96231b3b80d8
This doesn't set errno, so this should be OK.
Also update the documentation to explicitly state
that errno are not set.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200501 91177308-0d34-0410-b5e6-96231b3b80d8
coding standards, and instead fix the existing section.
Thanks to Daniel Jasper for pointing out we already had a section
devoted to this topic. Instead of adding sections, just hack on this
section some. Also fix the example in the anonymous namespace section
below it to agree with the new advice.
As a re-cap, this switches the LLVM preferred style to never indent
namespaces. Having two approaches just led to endless (and utterly
pointless) debates about what was "small enough". This wasn't helping
anyone. The no-indent rule is easy to understand and doesn't really make
anything harder to read. Moreover, with tools like clang-format it is
considerably nicer to have simple consistent rules.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199637 91177308-0d34-0410-b5e6-96231b3b80d8
(and to mention namespace ending comments). This is based on a quick
discussion on the developer mailing list where there was essentially no
objections to a simple and consistent rule. This should avoid future
debates about whether or not a namespace is "big enough" to indent. It
also matches clang-format's current behavior with LLVM source code which
hasn't really seen any opposition in code reviews that I spot checked.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199620 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The only current use of this flag is to mark the alloca as dynamic, even
if its in the entry block. The stack adjustment for the alloca can
never be folded into the prologue because the call may clear it and it
has to be allocated at the top of the stack.
Reviewers: majnemer
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2571
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199525 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds two new target-independent calling conventions for runtime
calls - PreserveMost and PreserveAll.
The target-specific implementation for X86-64 is defined as following:
- Arguments are passed as for the default C calling convention
- The same applies for the return value(s)
- PreserveMost preserves all GPRs - except R11
- PreserveAll preserves all GPRs and all XMMs/YMMs - except R11
Reviewed by Lang and Philip
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199508 91177308-0d34-0410-b5e6-96231b3b80d8
This makes things a lot easier, because we can now talk about the
"argument allocation", which allocates all the memory for the call in
one shot.
The only functional change is to the verifier for a feature that hasn't
shipped yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199434 91177308-0d34-0410-b5e6-96231b3b80d8
The line breaks around the "m:<mangling>" text in the Data Layout section
look weird. Let's see if this helps.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199285 91177308-0d34-0410-b5e6-96231b3b80d8
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199218 91177308-0d34-0410-b5e6-96231b3b80d8
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.
Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:
define available_externally dllimport void @f() {}
@Var = dllexport global i32 1, align 4
Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199204 91177308-0d34-0410-b5e6-96231b3b80d8
Use separate callee-save masks for XMM and YMM registers for anyregcc on X86 and
select the proper mask depending on the target cpu we compile for.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198985 91177308-0d34-0410-b5e6-96231b3b80d8
contributors to submit patches to the LLVM project. Thanks to Danny,
Chris, Alp, and others for reviewing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198901 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch any program that wanted to know the final symbol name of a
GlobalValue had to link with Target.
This patch implements a compromise solution where the mangler uses DataLayout.
This way, any tool that already links with Target (llc, clang) gets the exact
behavior as before and new IR files can be mangled without linking with Target.
With this patch the mangler is constructed with just a DataLayout and DataLayout
is extended to include the information the Mangler needs.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198438 91177308-0d34-0410-b5e6-96231b3b80d8
During the years there have been some attempts at figuring out how to
align byval arguments. A look at the commit log suggests that they
were
* Use the ABI alignment.
* When that was not sufficient for x86-64, I added the 's' specification to
DataLayout.
* When that was not sufficient Evan added the virtual getByValTypeAlignment.
* When even that was not sufficient, we just got the FE to add the alignment
to the byval.
This patch is just a simple cleanup that removes my first attempt at fixing the
problem. I also added an AArch64 implementation of getByValTypeAlignment to
make sure this patch is a nop. I also left the 's' parsing for backward
compatibility.
I will send a short email to llvmdev about the change for anyone maintaining
an out of tree target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198287 91177308-0d34-0410-b5e6-96231b3b80d8
These still have "experimental" status, meaning we don't guarantee
backward compatibility. However, they are already actively used by the
open source WebKit project, and have started to be adopted by other
projects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197930 91177308-0d34-0410-b5e6-96231b3b80d8
