| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NOTE: If you have any patches in the works that modify LangRef, you will
need to rewrite the changes to LangRef.html to their equivalents in
LangRef.rst. If you need assistance feel free to contact me.
Since LangRef is mission-critical for the project and "normative", I
have taken extra care to ensure that no content was lost or altered in
the conversion. The content was converted with a tool called `pandoc`,
so there is no chance for a human error like accidentally forgetting a
sentence or whatever. After the initial conversion by `pandoc`, only
changes to the markup were done.
This is just the most literal conversion of the HTML document as
possible. It might be worth exploring some way to chop up this massive
document into separate pages, e.g. something like
`docs/LangRef/Instructions.rst`, `docs/LangRef/Intrinsics.rst`, etc.
with `docs/LangRef.rst` being an "intro/navigation page" of sorts. On
the other hand, that loses the ability to {Ctrl,Cmd}-F for a given term
right from your browser.
IMO, I think our stylesheet needs some work because I find it hard to
tell what level of nesting some of the headings are at (e.g. "is this a
new section or is it a subsection?"). The issue is present on other
pages, but the sheer size and deep section structure of LangRef really
brings this issue out. If there are any web designers out there in the
community it would be awesome if you tried to come up with something
nicer.
llvm-svn: 169596
|
|
|
|
| |
llvm-svn: 169053
|
|
|
|
|
|
| |
flags.
llvm-svn: 169052
|
|
|
|
| |
llvm-svn: 168652
|
|
|
|
|
|
| |
parameter attributes.
llvm-svn: 168619
|
|
|
|
| |
llvm-svn: 168166
|
|
|
|
| |
llvm-svn: 168121
|
|
|
|
| |
llvm-svn: 168026
|
|
|
|
| |
llvm-svn: 168025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously in a vector of pointers, the pointer couldn't be any pointer type,
it had to be a pointer to an integer or floating point type. This is a hassle
for dragonegg because the GCC vectorizer happily produces vectors of pointers
where the pointer is a pointer to a struct or whatever. Vector getelementptr
was restricted to just one index, but now that vectors of pointers can have
any pointer type it is more natural to allow arbitrary vector getelementptrs.
There is however the issue of struct GEPs, where if each lane chose different
struct fields then from that point on each lane will be working down into
unrelated types. This seems like too much pain for too little gain, so when
you have a vector struct index all the elements are required to be the same.
llvm-svn: 167828
|
|
|
|
|
|
| |
preferred alignment. Correct the documentation.
llvm-svn: 166925
|
|
|
|
| |
llvm-svn: 166201
|
|
|
|
| |
llvm-svn: 165403
|
|
|
|
|
|
| |
alignment of the return type. Teach the optimizers this.
llvm-svn: 165226
|
|
|
|
|
|
| |
rest of LangRef uses.
llvm-svn: 164402
|
|
|
|
| |
llvm-svn: 164398
|
|
|
|
|
|
| |
inteldialect.
llvm-svn: 163231
|
|
|
|
| |
llvm-svn: 163181
|
|
|
|
|
|
|
| |
implementation does not co-exist well with how the sideeffect and alignstack
attributes are handled. The reverts r161641.
llvm-svn: 163174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make it more consistent with its intended semantics.
The `linker_private_weak_def_auto' linkage type was meant to automatically hide
globals which never had their addresses taken. It has nothing to do with the
`linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
among other things.
The intended semantic is more like the `linkonce_odr' linkage type.
Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
changing the semantics so that it produces the correct output for the linker.
Note: The old linkage name `linker_private_weak_def_auto' will still parse but
is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
<rdar://problem/11754934>
llvm-svn: 162114
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new attribute is intended to be used by the backend to determine how
the inline asm string should be parsed/printed. This patch adds the
ia_nsdialect attribute and also adds a test case to ensure the IR is
correctly parsed, but there is no functional change at this time.
The standard dialect is assumed to be AT&T. Therefore, this attribute
should only be added to MS-style inline assembly statements, which use
the Intel dialect. If we ever support more dialects we'll need to
add additional state to the attribute.
llvm-svn: 161641
|
|
|
|
| |
llvm-svn: 160791
|
|
|
|
| |
llvm-svn: 160762
|
|
|
|
| |
llvm-svn: 160621
|
|
|
|
|
|
| |
Update the language reference to reflect that.
llvm-svn: 160408
|
|
|
|
| |
llvm-svn: 159758
|
|
|
|
| |
llvm-svn: 159657
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the user/front-end to specify a model that is better
than what LLVM would choose by default. For example, a variable
might be declared as
@x = thread_local(initialexec) global i32 42
if it will not be used in a shared library that is dlopen'ed.
If the specified model isn't supported by the target, or if LLVM can
make a better choice, a different model may be used.
llvm-svn: 159077
|
|
|
|
|
|
|
|
|
|
| |
code to reprent information only used by the compiler)
Original commit msg:
add the 'alloc' metadata node to represent the size of offset of buffers pointed to by pointers.
This metadata can be attached to any instruction returning a pointer
llvm-svn: 158688
|
|
|
|
|
|
|
|
| |
pointed to by pointers.
This metadata can be attached to any instruction returning a pointer
llvm-svn: 158660
|
|
|
|
| |
llvm-svn: 158453
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression (a * b + c) that can be implemented as a fused multiply-add (fma)
if the target determines that this will be more efficient. This intrinsic
will be used to implement FP_CONTRACT support and an aggressive FMA formation
mode.
If your target has a fast FMA instruction you should override the
isFMAFasterThanMulAndAdd method in TargetLowering to return true.
llvm-svn: 158014
|
|
|
|
|
|
|
| |
Also make the checks stronger and test that we reject ranges that overlap
a previous wrapped range.
llvm-svn: 157749
|
|
|
|
|
|
|
|
|
|
|
| |
be non contiguous, non overlapping and sorted by the lower end.
While this is technically a backward incompatibility, every frontent currently
produces range metadata with a single interval and we don't have any pass
that merges intervals yet, so no existing bitcode files should be rejected by
this.
llvm-svn: 157741
|
|
|
|
| |
llvm-svn: 157661
|
|
|
|
| |
llvm-svn: 157551
|
|
|
|
|
|
|
|
|
|
| |
Submitted by: Anton Lokhmotov <Anton.Lokhmotov@arm.com>
Approved by: o Anton Korobeynikov
o Micah Villmow
o David Neto
llvm-svn: 157393
|
|
|
|
|
|
|
|
| |
objectsize intrinsic.
After a lot of discussion, we realized it's not the best option for run-time bounds checking
llvm-svn: 157255
|
|
|
|
| |
llvm-svn: 156881
|
|
|
|
| |
llvm-svn: 156774
|
|
|
|
|
|
| |
but it generates int3 on x86 instead of ud2.
llvm-svn: 156593
|
|
|
|
|
|
|
|
| |
maximum runtime performance penalty that the user is willing to accept.
This commit only adds the parameter. Code taking advantage of it will follow.
llvm-svn: 156473
|
|
|
|
|
|
| |
with Sphinx.
llvm-svn: 155153
|
|
|
|
| |
llvm-svn: 154850
|
|
|
|
|
|
|
|
|
| |
through the use of 'fpmath' metadata. Currently this only provides a 'fpaccuracy'
value, which may be a number in ULPs or the keyword 'fast', however the intent is
that this will be extended with additional information about NaN's, infinities
etc later. No optimizations have been hooked up to this so far.
llvm-svn: 154822
|
|
|
|
|
|
|
|
|
| |
thinking of generalizing it to be able to specify other freedoms beyond accuracy
(such as that NaN's don't have to be respected). I'd like the 3.1 release (the
first one with this metadata) to have the more generic name already rather than
having to auto-upgrade it in 3.2.
llvm-svn: 154744
|
|
|
|
|
|
| |
rational number, eg as 2.5 rather than 5, 2. OK'd by Peter Collingbourne.
llvm-svn: 154387
|
|
|
|
|
|
| |
less accurate method.
llvm-svn: 154319
|
|
|
|
| |
llvm-svn: 153508
|
|
|
|
|
|
| |
metadata.
llvm-svn: 153359
|