SelectionDAGIsel::LowerArguments needs a function, not a basic block. So it
makes sense to pass it the function instead of extracting a basic-block from
the function and then tossing it. This is also more self-documenting (functions
have arguments, BBs don't).
In addition, added comments to a couple of Select* methods.
llvm-svn: 176305
Test case is missing due to it not being reachable through the current tools
but out of tree code such as the sample at
http://llvm.org/docs/tutorial/LangImpl4.html
Patch by Peng Cheng <gm4cheng@gmail.com>
llvm-svn: 176213
enhancement done the trivial way; by extending inputs and truncating outputs
which is addequate for targets with little or no support for integer arithmetic
on integer types less than 32 bits.
llvm-svn: 176139
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
After cleaning up the following type hierarchies:
* TypeLoc: r175462
* SVal: r175594
* CFGElement: r175462
* ProgramPoint: r175812
that all invoked undefined behavior by causing a derived copy construction of a
base object through an invalid cast (thus supporting code that relied on
casting temporaries that were direct base objects) Clang/LLVM is now clean of
casts of temporaries. So here's some fun SFINAE machinery (courtesy of Eli
Friedman, with some porting back from C++11 to LLVM's traits by me) to cause
compile-time failures if llvm::cast & friends are ever passed an rvalue.
This should avoid a repeat of anything even remotely like PR14321/r168124.
Thanks to Jordan Rose for the help with the various Static Analyzer related
hierarchies that needed cleaning up, Eli for the SFINAE, Richard Smith, John
McCall, Ted Kremenek, and Anna Zaks for their input/reviews/patience along the
way.
llvm-svn: 175819
be set to zero that is what it was intended. Should improve performance of
the data structure when clear is invoked frequently (both compile time and
memory usage).
llvm-svn: 175799
to TargetFrameLowering, where it belongs. Incidentally, this allows us
to delete some duplicated (and slightly different!) code in TRI.
There are potentially other layering problems that can be cleaned up
as a result, or in a similar manner.
The refactoring was OK'd by Anton Korobeynikov on llvmdev.
Note: this touches the target interfaces, so out-of-tree targets may
be affected.
llvm-svn: 175788
This fixes some problems with too conservative checking where we were
marking all aliases of a register as used, and then also checking all
aliases when allocating a register.
<rdar://problem/13249625>
llvm-svn: 175782
Adding new segments to large LiveIntervals can be expensive because the
LiveRange objects after the insertion point may need to be moved left or
right. This can cause quadratic behavior when adding a large number of
segments to a live range.
The LiveRangeUpdater class allows the LIveInterval to be in a temporary
invalid state while segments are being added. It maintains an internal
gap in the LiveInterval when it is shrinking, and it has a spill area
for new segments when the LiveInterval is growing.
The behavior is similar to the existing mergeIntervalRanges() function,
except it allocates less memory for the spill area, and the algorithm is
turned inside out so the loop is driven by the clients.
llvm-svn: 175644
and removing instructions. The implementation seems more complicated than it
needs to be, but I couldn't find something simpler that dealt with all of the
corner cases.
Also add a call to repairIndexesInRange() from repairIntervalsInRange().
llvm-svn: 175601
This generalizes Optional to require less from the T type by using aligned
storage for backing & placement new/deleting the T into it when necessary.
Also includes unit tests.
llvm-svn: 175580
excluding visibility bits.
Mips (o32 abi) specific e_header setting.
EF_MIPS_ABI_O32 needs to be set in the
ELF header flags for o32 abi output.
Contributer: Reed Kotler
llvm-svn: 175569
excluding visibility bits.
Mips (Mips16) specific e_header setting.
EF_MIPS_ARCH_ASE_M16 needs to be set in the
ELF header flags for Mips16.
Contributer: Reed Kotler
llvm-svn: 175566
excluding visibility bits.
Mips (MicroMips) specific STO handling .
The st_other field settig for STO_MIPS_MICROMIPS
Contributer: Zoran Jovanovic
llvm-svn: 175564
excluding visibility bits.
Generic STO handling at the Target level.
The st_other field of the ELF symbol table is one
byte in size. The first 2 bytes are used for generic
visibility and are currently handled by llvm.
The other six bits are processor specific and need
to be set at the target level.
A couple of notes:
The new static methods for accessing and setting the "other"
flags in include/llvm/MC/MCELF.h match the style guide
and not the other methods in the file. I don't like the
inconsistency, but feel I should follow the prescribed
lowerUpper() convention.
STO_ value definitions are not specified in gnu land as
consistently as the STT_ and STB_ fields. Probably because
the latter were defined in a standards doc and the former
defined partially in code. I have stuck with the full byte
definition of the flags.
Contributer: Zoran Jovanovic
llvm-svn: 175561
Also, GetElementPtrInst::getType() method returns SequentialType now, instead of
PointerType. There wasn't any issue yet, so no testcase attached.
llvm-svn: 175452
arguably better than forward iterators for this use case, they are confusing and
there are some implementation problems with reverse iterators and MI bundles.
llvm-svn: 175393
terminators that actually have register uses when splitting critical edges.
This commit also introduces a method repairIntervalsInRange() on LiveIntervals,
which allows for repairing LiveIntervals in a small range after an arbitrary
target hook modifies, inserts, and removes instructions. It's pretty limited
right now, but I hope to extend it to support all of the things that are done
by the convertToThreeAddress() target hooks.
llvm-svn: 175382
Avoids malloc and is a lot denser. We lose iteration over target independent
attributes, but that's a strange interface anyways and didn't have any users
outside of AttrBuilder.
llvm-svn: 175370
If the frame pointer is omitted, and any stack changes occur in the inline
assembly, e.g.: "pusha", then any C local variable or C argument references
will be incorrect.
I pass no judgement on anyone who would do such a thing. ;)
rdar://13218191
llvm-svn: 175334
If two functions require different features (e.g., `-mno-sse' vs. `-msse') then
we want to honor that, especially during LTO. We can do that by resetting the
subtarget's features depending upon the 'target-feature' attribute.
llvm-svn: 175314
For some basic blocks, it is possible to generate many candidate pairs for
relatively few pairable instructions. When many (tens of thousands) of these pairs
are generated for a single instruction group, the time taken to generate and
rank the different vectorization plans can become quite large. As a result, we now
cap the number of candidate pairs within each instruction group. This is done by
closing out the group once the threshold is reached (set now at 3000 pairs).
Although this will limit the overall compile-time impact, this may not be the best
way to achieve this result. It might be better, for example, to prune excessive
candidate pairs after the fact the prevent the generation of short, but highly-connected
groups. We can experiment with this in the future.
This change reduces the overall compile-time slowdown of the csa.ll test case in
PR15222 to ~5x. If 5x is still considered too large, a lower limit can be
used as the default.
This represents a functionality change, but only for very large inputs
(thus, there is no regression test).
llvm-svn: 175251
validateSymbol() is called all over the place, and it seems it's a debug check.
It significantly speedups llvm-symbolizer used in tsan/asan/msan. validateSymbol() is the second hot function and accounts for 15% of runtime.
llvm-svn: 175192
Yiannis Tsiouris