This patch implements the infrastructure to use named register constructs in
programs that need access to specific registers (bare metal, kernels, etc).
So far, only the stack pointer is supported as a technology preview, but as it
is, the intrinsic can already support all non-allocatable registers from any
architecture.
llvm-svn: 208104
Summary:
* Updated the documentation
* Added a test for >2 arguments
* Added a check for the lexical concatenation
* Made the existing test a bit stricter.
Reviewers: t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, llvm-commits
Differential Revision: http://reviews.llvm.org/D3485
llvm-svn: 207865
Given the following C code llvm currently generates suboptimal code for
x86-64:
__m128 bss4( const __m128 *ptr, size_t i, size_t j )
{
float f = ptr[i][j];
return (__m128) { f, f, f, f };
}
=================================================
define <4 x float> @_Z4bss4PKDv4_fmm(<4 x float>* nocapture readonly %ptr, i64 %i, i64 %j) #0 {
%a1 = getelementptr inbounds <4 x float>* %ptr, i64 %i
%a2 = load <4 x float>* %a1, align 16, !tbaa !1
%a3 = trunc i64 %j to i32
%a4 = extractelement <4 x float> %a2, i32 %a3
%a5 = insertelement <4 x float> undef, float %a4, i32 0
%a6 = insertelement <4 x float> %a5, float %a4, i32 1
%a7 = insertelement <4 x float> %a6, float %a4, i32 2
%a8 = insertelement <4 x float> %a7, float %a4, i32 3
ret <4 x float> %a8
}
=================================================
shlq $4, %rsi
addq %rdi, %rsi
movslq %edx, %rax
vbroadcastss (%rsi,%rax,4), %xmm0
retq
=================================================
The movslq is uneeded, but is present because of the trunc to i32 and then
sext back to i64 that the backend adds for vbroadcastss.
We can't remove it because it changes the meaning. The IR that clang
generates is already suboptimal. What clang really should emit is:
%a4 = extractelement <4 x float> %a2, i64 %j
This patch makes that legal. A separate patch will teach clang to do it.
Differential Revision: http://reviews.llvm.org/D3519
llvm-svn: 207801
This introduces the stack lowering emission of the stack probe function for
Windows on ARM. The stack on Windows on ARM is a dynamically paged stack where
any page allocation which crosses a page boundary of the following guard page
will cause a page fault. This page fault must be handled by the kernel to
ensure that the page is faulted in. If this does not occur and a write access
any memory beyond that, the page fault will go unserviced, resulting in an
abnormal program termination.
The watermark for the stack probe appears to be at 4080 bytes (for
accommodating the stack guard canaries and stack alignment) when SSP is
enabled. Otherwise, the stack probe is emitted on the page size boundary of
4096 bytes.
llvm-svn: 207615
This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur. It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.
Reviewers: nicholas
Differential Revision: http://llvm-reviews.chandlerc.com/D3240
llvm-svn: 207143
The option LLVM_ENABLE_SPHINX option enables the "docs-llvm-html",
"docs-llvm-man" targets but does not build them by default. The
following CMake options have been added that control what targets are
made available
SPHINX_OUTPUT_HTML
SPHINX_OUTPUT_MAN
If LLVM_BUILD_DOCS is enabled then the enabled docs-llvm-* targets will
be built by default and if ``make install`` is run then docs-llvm-html
and docs-llvm-man will be installed (tested on Linux only).
The add_sphinx_target function is in its own file so it can be included
by other projects that use Sphinx for their documentation.
Patch by Daniel Liew <daniel.liew@imperial.ac.uk>!
llvm-svn: 206655
This pass was removed in r184459.
Also added note that the InstCombine pass does library call
simplification.
Patch slightly modified from one by Daniel Liew
<daniel.liew@imperial.ac.uk>!
llvm-svn: 206650
This removes the -segmented-stacks command line flag in favor of a
per-function "split-stack" attribute.
Patch by Luqman Aden and Alex Crichton!
llvm-svn: 205997
:doc:`...` and :ref:`...` links help Sphinx keep track the dependencies
between documents and ensure that they are not pointing to nowhere.
Raw HTML links work just fine and are easier for people less familiar
with reST/Sphinx. They are easy to change over to the :doc:/:ref: style
after the fact so this is not a problem.
This commit doesn't fix all of them.
llvm-svn: 205792
Making the new TableGen documentation official and marking the old file as
"Moved". Also, reverting the original LangRef as the normative formal
description of the language, while keeping the "new" LangRef as LangIntro
for the less inlcined to reading language grammars.
We should remove TableGenFundamentals.rst one day, but for now, just a
warning that it moved will have to do, while we make sure there are no more
links to it from elsewhere.
llvm-svn: 205289
This commit updates the stackmap format to version 1 to indicate the
reorganizaion of several fields. This was done in order to align stackmap
entries to their natural alignment and to minimize padding.
Fixes <rdar://problem/16005902>
llvm-svn: 205254
The non-SJLJ and SJLJ intrinsics are generated by the frontend and
backend respectively.
Differential Revision: http://llvm-reviews.chandlerc.com/D3010
llvm-svn: 205017
This adds back r204781.
Original message:
Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given
define void @my_func() {
ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias
We produce without this patch:
.weak my_alias
my_alias = my_func
.globl my_alias2
my_alias2 = my_alias
That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a
@my_alias = alias void ()* @other_func
would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.
There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.
llvm-svn: 204934
The LangRef warning wasn't formatting the way I intended it to anyway.
Surprisingly inalloca appears to work, even when optimizations are
enabled. We generate very bad code for it, but we can self-host and run
lots of big tests.
llvm-svn: 204888
After some discussion on IRC, emitting a call to the library function seems
like a better default, since it will move from a compiler internal error to
a linker error, that the user can work around until LLVM is fixed.
I'm also adding a note on the responsibility of the user to confirm that
the cache was cleared on platforms where nothing is done.
llvm-svn: 204806
Implementing the LLVM part of the call to __builtin___clear_cache
which translates into an intrinsic @llvm.clear_cache and is lowered
by each target, either to a call to __clear_cache or nothing at all
incase the caches are unified.
Updating LangRef and adding some tests for the implemented architectures.
Other archs will have to implement the method in case this builtin
has to be compiled for it, since the default behaviour is to bail
unimplemented.
A Clang patch is required for the builtin to be lowered into the
llvm intrinsic. This will be done next.
llvm-svn: 204802
This reverts commit r204781.
I will follow up to with msan folks to see what is what they
were trying to do with aliases to weak aliases.
llvm-svn: 204784
Aliases are just another name for a position in a file. As such, the
regular symbol resolutions are not applied. For example, given
define void @my_func() {
ret void
}
@my_alias = alias weak void ()* @my_func
@my_alias2 = alias void ()* @my_alias
We produce without this patch:
.weak my_alias
my_alias = my_func
.globl my_alias2
my_alias2 = my_alias
That is, in the resulting ELF file my_alias, my_func and my_alias are
just 3 names pointing to offset 0 of .text. That is *not* the
semantics of IR linking. For example, linking in a
@my_alias = alias void ()* @other_func
would require the strong my_alias to override the weak one and
my_alias2 would end up pointing to other_func.
There is no way to represent that with aliases being just another
name, so the best solution seems to be to just disallow it, converting
a miscompile into an error.
llvm-svn: 204781
This option caused LowerInvoke to generate code using SJLJ-based
exception handling, but there is no code left that interprets the
jmp_buf stack that the resulting code maintained (llvm.sjljeh.jblist).
This option has been obsolete for a while, and replaced by
SjLjEHPrepare.
This leaves the default behaviour of LowerInvoke, which is to convert
invokes to calls.
Differential Revision: http://llvm-reviews.chandlerc.com/D3136
llvm-svn: 204388
This is mainly a movement of content around to give place to new content
allowing different people to add bits to it in the right place. There is some
new content, but mostly to fill the gaps left by text movement.
I'm dropping the old syntax documentation as it has the problem of being
quickly outdated by changes and largely unnecessary to people not involved
in creating the language, but using it, which is the whole point of the
documentation.
llvm-svn: 204351
This allows us to catch more opportunities for ODR-based type uniquing
during LTO.
Paired commit with CFE which updates some testcases to verify the new
DIBuilder behavior.
llvm-svn: 204106
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:
* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.
It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.
With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.
The objc uses are currently split in
* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.
The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are
* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.
Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.
For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).
llvm-svn: 203866
As an example that was not actually being used, it suffered from a slow bitrot.
The two main issues with it were that it had no cmake support and
included a copy of the autoconf directory. The reality is that
autoconf is not easily composable. The lack of composabilty is why we
have clang options in llvm's configure. Suggesting that users include
a copy of autoconf/ in their projects seems a bad idea.
We are also in the process of switching to cmake, so pushing autoconf
to new project is probably not what we want.
llvm-svn: 203728
On ELF and COFF an alias is just another name for a position in the file.
There is no way to refer to a position in another file, so an alias to
undefined is meaningless.
MachO currently doesn't support aliases. The spec has a N_INDR, which when
implemented will have a different set of restrictions. Adding support for
it shouldn't be harder than any other IR extension.
For now, having the IR represent what is actually possible with current
tools makes it easier to fix the design of GlobalAlias.
llvm-svn: 203705
The syntax for "cmpxchg" should now look something like:
cmpxchg i32* %addr, i32 42, i32 3 acquire monotonic
where the second ordering argument gives the required semantics in the case
that no exchange takes place. It should be no stronger than the first ordering
constraint and cannot be either "release" or "acq_rel" (since no store will
have taken place).
rdar://problem/15996804
llvm-svn: 203559
The official specifications state the name to be ARMNT (as per the Microsoft
Portable Executable and Common Object Format Specification v8.3).
llvm-svn: 203530
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.
llvm-svn: 203376
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.
llvm-svn: 202973
The correct name of the type in LLVM assembly is "x86_mmx". Also remove
the reST label "t_x86mmx" because it was unused anyway.
Patch by Manuel Jacob!
Differential Revision: http://llvm-reviews.chandlerc.com/D2955
llvm-svn: 202929
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.
llvm-svn: 202824
We'd like to keep the clang-cl self-host working until we implement
MSVC-compatible RTTI.
Differential Revision: http://llvm-reviews.chandlerc.com/D2930
llvm-svn: 202758
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.
llvm-svn: 202729
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.
llvm-svn: 202728
facilitate the nice formatting of lambdas passed there. Suggested by
Chris during review of my lambda additions, and something I strongly
agree with.
llvm-svn: 202622
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.
llvm-svn: 202620
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.
llvm-svn: 202603
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.
llvm-svn: 202566
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.
llvm-svn: 202548
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. =]
llvm-svn: 202497
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.
llvm-svn: 202495
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.
llvm-svn: 202486
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".
llvm-svn: 202430
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. =]
llvm-svn: 202375
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.
llvm-svn: 202373
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.
llvm-svn: 202370
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.
llvm-svn: 202209
This replaces the old NoIntegratedAssembler with at TargetOption. This is
more flexible and will be used to forward clang's -no-integrated-as option.
llvm-svn: 201836
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.
llvm-svn: 201619
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.
llvm-svn: 201616
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>
llvm-svn: 201535
I noticed this convention from the commit logs. It seems like it
would be useful to document it, to encourage other committers to link
back to code reviews in their commits.
Differential Revision: http://llvm-reviews.chandlerc.com/D2678
llvm-svn: 201160
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.
llvm-svn: 201035
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
}]>;
llvm-svn: 201033
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.
llvm-svn: 200664
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
llvm-svn: 200601
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
llvm-svn: 200596
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
llvm-svn: 200561
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.
llvm-svn: 199637
(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.
llvm-svn: 199620
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
llvm-svn: 199525
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
llvm-svn: 199508
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.
llvm-svn: 199434
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.
llvm-svn: 199218
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.
llvm-svn: 199204
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.
llvm-svn: 198985
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.
llvm-svn: 198438
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.
llvm-svn: 198287
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.
llvm-svn: 197930
The inalloca attribute is designed to support passing C++ objects by
value in the Microsoft C++ ABI. It behaves the same as byval, except
that it always implies that the argument is in memory and that the bytes
are never copied. This attribute allows the caller to take the address
of an outgoing argument's memory and execute arbitrary code to store
into it.
This patch adds basic IR support, docs, and verification. It does not
attempt to implement any lowering or fix any possibly broken transforms.
When this patch lands, a complete description of this feature should
appear at http://llvm.org/docs/InAlloca.html .
Differential Revision: http://llvm-reviews.chandlerc.com/D2173
llvm-svn: 197645
They were out of place since the introduction of arbitrary precision integer
types.
This also synchronizes the documentation to Types.h, so it refers to first class
types and single value types.
llvm-svn: 196661
It appears to be referring to nonexistent entities. This must be a
carry-over from an older version of the document.
Patch by Mikael Lyngvig!
llvm-svn: 196342
* Update build instructions to reflect the current source tree layout.
* Don't inflict CVS on readers; there's a perfectly good git mirror.
* configure with --disable-werror making it possible to build using clang.
* ar and nm-new now support the -plugin option.
llvm-svn: 196069
In some case, it may be required to build LLVM in C++11 mode, as some the subprojects (like lldb) requires it.
This mimics the autoconf behaviour.
However, given the discussions on the switch to C++11 of the codebase, this behaviour should evolve to default to C++11 with some checks of the compiler capabilities.
llvm-svn: 195727
MappingTrait template specializations can now have a validate() method which
performs semantic checking. For details, see <http://llvm.org/docs/YamlIO.html>.
llvm-svn: 195286
This is the first step to fix pr17918.
It extends the .section directive a bit, inspired by what the ELF one looks
like. The problem with using linkonce is that given
.section foo
.linkonce....
.section foo
.linkonce
we would already have switched sections when getting to .linkonce. The cleanest
solution seems to be to add the comdat information in the .section itself.
llvm-svn: 195148
(except functions marked always_inline).
Functions with 'optnone' must also have 'noinline' so they don't get
inlined into any other function.
Based on work by Andrea Di Biagio.
llvm-svn: 195046
for release builds.
This is a follow-up to r194589. Aaron pointed out that building
libraries with /MT and using them in an application that uses a
different run-time library can be a bad idea.
Move the option to build with /MT behind a CMake option so it can be
turned on selectively, such as when building the toolchain installer.
llvm-svn: 194596
after the 3.4 release to the release notes. See the *lengthy* llvmdev
and cfe-dev threads on this subject. There will be more emails,
discussion and announcements, but I want to make noise in as many places
as I can to get everyone's concerns voiced and understood.
llvm-svn: 194183
linkonce_odr_auto_hide was in incomplete attempt to implement a way
for the linker to hide symbols that are known to be available in every
TU and whose addresses are not relevant for a particular DSO.
It was redundant in that it all its uses are equivalent to
linkonce_odr+unnamed_addr. Unlike those, it has never been connected
to clang or llvm's optimizers, so it was effectively dead.
Given that nothing produces it, this patch just nukes it
(other than the llvm-c enum value).
llvm-svn: 193865
Currently, instead of showing up as link, it is rendered as
...of FunctionPass <writing-an-llvm-pass-FunctionPass>. The...
PR17733. Patch by Tay Ray Chuan!
llvm-svn: 193698
Major steps include:
1). introduces a not-addr-taken bit-field in GlobalVariable
2). GlobalOpt pass sets "not-address-taken" if it proves a global varirable
dosen't have its address taken.
3). AA use this info for disambiguation.
llvm-svn: 193251
There doesn't seem to be a need in checking if a directory exists if we
will just rm -rf it once we affirm that it does. Instead, just blindly
try to delete it.
This fixes PR17541.
llvm-svn: 192679
part of getting started with LLVM.
The LLVM getting started document is in woeful need of attention. I may
get to some of this, but some random notes for folks interested:
1) We need to separate the getting started steps for folks who are
interested in the core LLVM libs and nothing else, folks interested
in a nifty C++ toolchain and nothing else, and folks interested in
both.
2) We should include documentation for both release archives, svn, and
git in equal portion, and we should document all of the various
repositories of interest: llvm, clang, clang-tools-extra,
compiler-rt, lld, libcxx, test-suite.
3) We should document the CMake build. We should probably document the
CMake build first, and give a fall-back set of docs for the Makefile
build for the use cases where that is still the preferred solution.
This would more closely match the use cases that folks in the open
source community are likely to have, and would remove a point of
discrepancy between Linux, Windows, and Mac instructions.
4) Probably a ton of other modernization stuff that I've not thought of
here.
Anyways, if anyone at all is interested, please help clean up this
document. It is much needed.
llvm-svn: 189732
implementation files. While doc generation systems don't need this,
humans do benefit from it. Not everyone reads all code through doxygen.
llvm-svn: 189704
This function attribute indicates that the function is not optimized
by any optimization or code generator passes with the
exception of interprocedural optimization passes.
llvm-svn: 189101
This adds a llvm.copysign intrinsic; We already have Libfunc recognition for
copysign (which is turned into the FCOPYSIGN SDAG node). In order to
autovectorize calls to copysign in the loop vectorizer, we need a corresponding
intrinsic as well.
In addition to the expected changes to the language reference, the loop
vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into
an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a
few lists in LegalizeVector{Ops,Types} so that vector copysigns can be
expanded.
In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN
be Expand for vector types. This seems correct for all in-tree targets, and I
think is the right thing to do because, previously, there was no way to generate
vector-values FCOPYSIGN nodes (and most targets don't specify an action for
vector-typed FCOPYSIGN).
llvm-svn: 188728
All libm floating-point rounding functions, except for round(), had their own
ISD nodes. Recent PowerPC cores have an instruction for round(), and so here I'm
adding ISD::FROUND so that round() can be custom lowered as well.
For the most part, this is straightforward. I've added an intrinsic
and a matching ISD node just like those for nearbyint() and friends. The
SelectionDAG pattern I've named frnd (because ISD::FP_ROUND has already claimed
fround).
This will be used by the PowerPC backend in a follow-up commit.
llvm-svn: 187926
This change makes test with RUN lines like
RUN: opt ... | FileCheck
fail if opt fails, even if it prints what FileCheck wants. Enabling this
found some interesting cases of broken tests that were not being noticed
because opt (or some other tool) was crashing late.
Pipefail is used when the shell supports it or when using the internal
python based tester.
llvm-svn: 187261
Back in r140220 we removed the autoconf code that would set LLVMCC_OPTION
since it was only used by the test-suite. This patch now removes code
that would only be used if LLVMCC_OPTION was set.
llvm-svn: 187154
CHECK-LABEL is meant to be used in place on CHECK on lines containing identifiers or other unique labels (they need not actually be labels in the source or output language, though.) This is used to break up the input stream into separate blocks delineated by CHECK-LABEL lines, each of which is checked independently. This greatly improves the accuracy of errors and fix-it hints in many cases, and allows for FileCheck to recover from errors in one block by continuing to subsequent blocks.
Some tests will be converted to use this new directive in forthcoming patches.
llvm-svn: 186162
"Writing an LLVM Compiler Backend" can be misinterpreted as meaning
"backend" in the sense of "using LLVM as a backend for your compiler for
your new language". This new name is less ambiguous.
As a bonus, this brings the title in line with the file name.
llvm-svn: 185377
The Builtin attribute is an attribute that can be placed on function call site that signal that even though a function is declared as being a builtin,
rdar://problem/13727199
llvm-svn: 185049
This patch modifies TableGen to generate a function in
${TARGET}GenInstrInfo.inc called getNamedOperandIdx(), which can be used
to look up indices for operands based on their names.
In order to activate this feature for an instruction, you must set the
UseNamedOperandTable bit.
For example, if you have an instruction like:
def ADD : TargetInstr <(outs GPR:$dst), (ins GPR:$src0, GPR:$src1)>;
You can look up the operand indices using the new function, like this:
Target::getNamedOperandIdx(Target::ADD, Target::OpName::dst) => 0
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src0) => 1
Target::getNamedOperandIdx(Target::ADD, Target::OpName::src1) => 2
The operand names are case sensitive, so $dst and $DST are considered
different operands.
This change is useful for R600 which has instructions with a large number
of operands, many of which model single bit instruction configuration
values. These configuration bits are common across most instructions,
but may have a different operand index depending on the instruction type.
It is useful to have a convenient way to look up the operand indices,
so these bits can be generically set on any instruction.
llvm-svn: 184879
Archive files (.a) can have a symbol table indicating which object
files in them define which symbols. The purpose of this symbol table
is to speed up linking by allowing the linker the read only the .o
files it is actually going to use instead of having to parse every
object's symbol table.
LLVM's archive library currently supports a LLVM specific format for
such table. It is hard to see any value in that now that llvm-ld is
gone:
* System linkers don't use it: GNU ar uses the same plugin as the
linker to create archive files with a regular index. The OS X ar
creates no symbol table for IL files, I assume the linker just parses
all IL files.
* It doesn't interact well with archives having both IL and native objects.
* We probably don't want to be responsible for yet another archive
format variant.
This patch then:
* Removes support for creating and reading such index from lib/Archive.
* Remove llvm-ranlib, since there is nothing left for it to do.
We should in the future add support for regular indexes to llvm-ar for
both native and IL objects. When we do that, llvm-ranlib should be
reimplemented as a symlink to llvm-ar, as it is equivalent to "ar s".
llvm-svn: 184019
The effect of llvm.used is to introduce an invisible reference, so this seems
a reasonable restriction. It will be used to provide an easy ordering of
the entries in llvm.used.
llvm-svn: 183743
Several LLVM headers are moved. The code listings in
LLVM tutorial are not updated yet.
This CL removes the code replica in the .rst, and replace
them with a literalinclude directive, so that sphinx can
include the latest code automatically.
llvm-svn: 183607
This updates the debug info metadata schema documentation for various
schema changes made recently surrounding filename information for
scopes and the representation of imported entities.
llvm-svn: 182817
- llvm.loop.parallel metadata has been renamed to llvm.loop to be more generic
by making the root of additional loop metadata.
- Loop::isAnnotatedParallel now looks for llvm.loop and associated
llvm.mem.parallel_loop_access
- document llvm.loop and update llvm.mem.parallel_loop_access
- add support for llvm.vectorizer.width and llvm.vectorizer.unroll
- document llvm.vectorizer.* metadata
- add utility class LoopVectorizerHints for getting/setting loop metadata
- use llvm.vectorizer.width=1 to indicate already vectorized instead of
already_vectorized
- update existing tests that used llvm.loop.parallel and
llvm.vectorizer.already_vectorized
Reviewed by: Nadav Rotem
llvm-svn: 182802
Other than recognizing the attribute, the patch does little else.
It changes the branch probability analyzer so that edges into
blocks postdominated by a cold function are given low weight.
Added analysis and code generation tests. Added documentation for the
new attribute.
llvm-svn: 182638
This implements the @llvm.readcyclecounter intrinsic as the specific
MRC instruction specified in the ARM manuals for CPUs with the Power
Management extensions.
Older CPUs had slightly different methods which may also have to be
implemented eventually, but this should cover all v7 cases.
rdar://problem/13939186
llvm-svn: 182603
Describe that they are assigned numbered label using the same counter
as for unnamed temporaries.
Based on http://llvm.org/bugs/show_bug.cgi?id=16043 and mailing list
discussion.
Patch by Paul Sokolovsky!
llvm-svn: 182332
Summary:
This patch allows using \n inside long help strings for command-line
options, so that all lines are equally indented. This is not a perfect solution,
as we don't (and probably don't want to) know about terminal width, but it
allows to format long help strings somehow readable without manually padding
them with spaces. A motivating example is -help output from clang-format (source
code in tools/clang-format/ClangFormat.cpp, see cl options offset, length,
style, and dump-config).
Reviewers: atrick, alexfh
Reviewed By: alexfh
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D779
llvm-svn: 181608
The idea is that docs/ReleaseNotes.rst is 3.3 and will be copied to the
branch by the release manager just before creating the release
candidates.
This ReleaseNotes_34.rst will then be moved over ReleaseNotes.rst after
the 3.3 release.
llvm-svn: 181349
This patch wires up the SystemZ target in configure, so that it can now be
built using --enable-targets=systemz. It is not yet included in the default
build (--enable-targets=all); this will be done by a follow-up patch.
Patch by Richard Sandiford.
llvm-svn: 181208
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.
llvm-svn: 181009
This option expands shown relocations from single line to a dictionary
format:
Relocation {
Offset: 0x4
Type: R_386_32 (1)
Symbol: sym
Info: 0x0
}
llvm-svn: 179359
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'.
llvm-svn: 179240
Summary: This is the beginning of user documentation for the NVPTX back-end. I want to ensure I am integrating this properly into the rest of the LLVM documentation.
Differential Revision: http://llvm-reviews.chandlerc.com/D600
llvm-svn: 178428
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.
llvm-svn: 178425
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.
llvm-svn: 178376
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)>;
llvm-svn: 177843
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).
llvm-svn: 177778
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.
llvm-svn: 177428
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
llvm-svn: 176075
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.
llvm-svn: 175835
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.
llvm-svn: 174961
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!
llvm-svn: 174739
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.
llvm-svn: 174493
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'.
llvm-svn: 174313
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
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.
llvm-svn: 174144
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.
llvm-svn: 174054
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
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
Justin Bogner