This implies changing method documentation from the following style:
/// MethodName - Method description...
to
/// \brief Method description...
ala the LLVM Style Guide.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172959 91177308-0d34-0410-b5e6-96231b3b80d8
This method serves an analogous purpose to CreateZExtOrTrunc/CreateSExtOrTrunc
but for floating point types.
In detail, it provides a manner when one is handling conversions of floating
point types of automatically selecting fpext, fptrunc, or identity depending on
the relative bitsize of the source and destination types.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172957 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
We weren't encoding boolean constants correctly due to modeling boolean as a
signed type & then sign extending an i1 up to a byte & getting 255.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172926 91177308-0d34-0410-b5e6-96231b3b80d8
through a BitstreamCursor that produce it: advance() and
advanceSkippingSubblocks(), representing the two most common ways clients
want to walk through bitcode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172919 91177308-0d34-0410-b5e6-96231b3b80d8
has past the point of making sense. Lets tidy things up: first step, moving
a ton of big functions out of line.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172904 91177308-0d34-0410-b5e6-96231b3b80d8
This separates the check for "too few elements to run the vector loop" from the
"memory overlap" check, giving a lot nicer code and allowing to skip the memory
checks when we're not going to execute the vector code anyways. We still leave
the decision of whether to emit the memory checks as branches or setccs, but it
seems to be doing a good job. If ugly code pops up we may want to emit them as
separate blocks too. Small speedup on MultiSource/Benchmarks/MallocBench/espresso.
Most of this is legwork to allow multiple bypass blocks while updating PHIs,
dominators and loop info.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172902 91177308-0d34-0410-b5e6-96231b3b80d8
but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.
Formatting fixes. Mostly long lines and
blank spaces at end of lines.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172882 91177308-0d34-0410-b5e6-96231b3b80d8
configure checks whether -Wno-missing-field-initializers is a valid
compiler flag but it was never actually used in Makefile.rules.
Enable it to avoid some ridiculous warnings from gcc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172870 91177308-0d34-0410-b5e6-96231b3b80d8
Further encapsulation of the Attribute object. Don't allow direct access to the
Attribute object as an aggregate.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172853 91177308-0d34-0410-b5e6-96231b3b80d8
but I cannot reproduce the problem and have scrubed my sources and
even tested with llvm-lit -v --vg.
Support for Mips register information sections.
Mips ELF object files have a section that is dedicated
to register use info. Some of this information such as
the assumed Global Pointer value is used by the linker
in relocation resolution.
The register info file is .reginfo in o32 and .MIPS.options
in 64 and n32 abi files.
This patch contains the changes needed to create the sections,
but leaves the actual register accounting for a future patch.
Contributer: Jack Carter
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172847 91177308-0d34-0410-b5e6-96231b3b80d8
Some instructions like memory reads/writes are executed
asynchronously, so we need to insert S_WAITCNT instructions
to block before accessing their results. Previously we have
just inserted S_WAITCNT instructions after each async
instruction, this patch fixes this and adds a prober
insertion pass.
Patch by: Christian König
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172846 91177308-0d34-0410-b5e6-96231b3b80d8
We shouldn't insert KILL optimization if we don't have a
kill instruction at all.
Patch by: Christian König
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
Signed-off-by: Christian König <deathsimple@vodafone.de>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172845 91177308-0d34-0410-b5e6-96231b3b80d8
