manually performing the comparison. This allows the special
case to work correctly even in the case where someone is
experimenting with a different comparison function :-).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49670 91177308-0d34-0410-b5e6-96231b3b80d8
stack tracebacks on Darwin x86-64 won't work by default;
nevertheless, everybody but me thinks this is a good idea.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49663 91177308-0d34-0410-b5e6-96231b3b80d8
much simpler than in LegalizeDAG because calls are
not yet expanded into call sequences: that happens
after type legalization has finished.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49634 91177308-0d34-0410-b5e6-96231b3b80d8
in its maps. Add some sanity checks that catch
this kind of thing. Hopefully these can be
removed one day (once all problems are fixed!)
but for the moment it seems wise to have them in.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49612 91177308-0d34-0410-b5e6-96231b3b80d8
optimized x86-64 (and x86) calls so that they work (... at least for
my test cases).
Should fix the following problems:
Problem 1: When i introduced the optimized handling of arguments for
tail called functions (using a sequence of copyto/copyfrom virtual
registers instead of always lowering to top of the stack) i did not
handle byval arguments correctly e.g they did not work at all :).
Problem 2: On x86-64 after the arguments of the tail called function
are moved to their registers (which include ESI/RSI etc), tail call
optimization performs byval lowering which causes xSI,xDI, xCX
registers to be overwritten. This is handled in this patch by moving
the arguments to virtual registers first and after the byval lowering
the arguments are moved from those virtual registers back to
RSI/RDI/RCX.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49584 91177308-0d34-0410-b5e6-96231b3b80d8
on any current target and aren't optimized in DAGCombiner. Instead
of using intermediate nodes, expand the operations, choosing between
simple loads/stores, target-specific code, and library calls,
immediately.
Previously, the code to emit optimized code for these operations
was only used at initial SelectionDAG construction time; now it is
used at all times. This fixes some cases where rep;movs was being
used for small copies where simple loads/stores would be better.
This also cleans up code that checks for alignments less than 4;
let the targets make that decision instead of doing it in
target-independent code. This allows x86 to use rep;movs in
low-alignment cases.
Also, this fixes a bug that resulted in the use of rep;stos for
memsets of 0 with non-constant memory size when the alignment was
at least 4. It's better to use the library in this case, which
can be significantly faster when the size is large.
This also preserves more SourceValue information when memory
intrinsics are lowered into simple loads/stores.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49572 91177308-0d34-0410-b5e6-96231b3b80d8
in addition to integer expressions. Rewrite GetOrEnforceKnownAlignment
as a ComputeMaskedBits problem, moving all of its special alignment
knowledge to ComputeMaskedBits as low-zero-bits knowledge.
Also, teach ComputeMaskedBits a few basic things about Mul and PHI
instructions.
This improves ComputeMaskedBits-based simplifications in a few cases,
but more noticeably it significantly improves instcombine's alignment
detection for loads, stores, and memory intrinsics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49492 91177308-0d34-0410-b5e6-96231b3b80d8
MOVZQI2PQIrr. This would be better handled as a dag combine
(with the goal of eliminating the bitconvert) but I don't know
how to do that safely. Thoughts welcome.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49463 91177308-0d34-0410-b5e6-96231b3b80d8
is needed for the x86-64-ABI handling of structs that contain floating-point
members that are returned by value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49441 91177308-0d34-0410-b5e6-96231b3b80d8
in both time and memory savings for GVN. For example, one testcase went from 10.5s to 6s with
this patch.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49345 91177308-0d34-0410-b5e6-96231b3b80d8
needs to be fixed here - a previous commit made sure
that intrinsics always get the right attributes.
So remove no-longer needed code, and while there use
Intrinsic::getDeclaration rather than getOrInsertFunction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49337 91177308-0d34-0410-b5e6-96231b3b80d8
nounwind. When such calls are inlined into something
else that is invoked, they were getting changed to invokes,
which is badness.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49299 91177308-0d34-0410-b5e6-96231b3b80d8
If it cannot be expanded, it will keep the old behaviour and try to shrink the constant.
Part of enhancement for PR2191.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49280 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, introduction of XXX::Create methods
for Users that have a potentially variable number of
Uses.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49277 91177308-0d34-0410-b5e6-96231b3b80d8
2. Coalescer can now create an interesting situation where a register def can
reaches itself without being killed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49246 91177308-0d34-0410-b5e6-96231b3b80d8
before an invoke. Failure to do this causes references in
the landing pad to variables that were not set. Fixes
g++.dg/eh/delayslot1.C
g++.dg/eh/fp-regs.C
g++.old-deja/g++.brendan/eh1.C
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49243 91177308-0d34-0410-b5e6-96231b3b80d8
tools. This is currently only enabled on the mac, but could easily be
supported by other hosts that are interested.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49207 91177308-0d34-0410-b5e6-96231b3b80d8
There is no point in creating a long live range defined by an implicit_def. Scheduler now duplicates implicit_def instruction for each of its uses. Therefore, if an implicit_def node has multiple uses, it will become a number of very short live ranges, rather than a long one. This will make coalescer's job easier.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49164 91177308-0d34-0410-b5e6-96231b3b80d8
This method allows one to create a directory, and optionally create all parent
directories that do not exist.
The original implementation would require that *all* directories along a path
are writable by the user, including directories that already exist. For example,
suppose we wanted to create the directory "/tmp/foo/bar", and the directory
"/tmp" already exists, but not "/tmp/foo". Since "/tmp" is writable by all
users, the original implementation would work, and create "/tmp/foo", followed
by "/tmp/bar".
A problem occurred, however if one wanted to created the directory
"/Users/myuser/bar" (or equivalently "/home/myuser/bar"), and "/Users/myuser"
already existed and is writable by the current user. The directory
"/User/myuser" is writable by the user, but "/User" is not. The original
implementation of createDirectoryOnDisk would return with failure since "/User"
is not writable, even though "/User/mysuser" is writable.
The new implementation works by recursively creating parents as needed, and thus
doesn't need to check the permissions on every directory in a path.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49162 91177308-0d34-0410-b5e6-96231b3b80d8
don't access cached iterators from after the erased element.
Re-apply 49056 with SmallVector support.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49106 91177308-0d34-0410-b5e6-96231b3b80d8
review feedback.
-enable-eh is still accepted but doesn't do anything.
EH intrinsics use Dwarf EH if the target supports that,
and are handled by LowerInvoke otherwise.
The separation of the EH table and frame move data is,
I think, logically figured out, but either one still
causes full EH info to be generated (not sure how to
split the metadata correctly).
MachineModuleInfo::needsFrameInfo is no longer used and
is removed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49064 91177308-0d34-0410-b5e6-96231b3b80d8
2. Do not use # of basic blocks as part of the cost computation since it doesn't really figure into function size.
3. More aggressively inline function with vector code.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49061 91177308-0d34-0410-b5e6-96231b3b80d8
start of a filename, not a filename+length. All clients can produce a
null terminated name, and the system api's require null terminated
strings anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49041 91177308-0d34-0410-b5e6-96231b3b80d8
1) stop using MappedFile.
2) if profitable use the sys::path::MapInFilePages api to
read the file.
3) otherwise fallback to read.
When sys::path::MapInFilePages is implemented, this provides
several benefits:
#1: this avoids fragmenting memory for small files.
#2: this avoids extraneous stat calls when the file size is known.
#3: this only keeps the file descriptor open while reading the
file, not for the duration of the lifetime of the memory
buffer. This fixes a serious clang FD 'leak' problem.
I believe that this will work on a win32 machine, but I don't have
one to test on. I'd appreciate it if someone could check.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49031 91177308-0d34-0410-b5e6-96231b3b80d8
not an mmapped file. This more closely matches its requirements and
provides an implicitly null terminated buffer, something this
routine had to emulate itself before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49024 91177308-0d34-0410-b5e6-96231b3b80d8
tons of out of date comments (really nothing throws here!) and fixes
some other fairly glaring issues: "size" used to return the size of
the file *and* change it, depending on how you called it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49009 91177308-0d34-0410-b5e6-96231b3b80d8
not marked nounwind, or for all functions when -enable-eh
is set, provided the target supports Dwarf EH.
llvm-gcc generates nounwind in the right places; other FEs
will need to do so also. Given such a FE, -enable-eh should
no longer be needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@49006 91177308-0d34-0410-b5e6-96231b3b80d8
