To quote the langref "Unlike sqrt in libm, however, llvm.sqrt has
undefined behavior for negative numbers other than -0.0 (which allows
for better optimization, because there is no need to worry about errno
being set). llvm.sqrt(-0.0) is defined to return -0.0 like IEEE sqrt."
This means that it's unsafe to replace sqrt with llvm.sqrt unless the
call is annotated with nnan.
Thanks to Hal Finkel for pointing this out!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265521 91177308-0d34-0410-b5e6-96231b3b80d8
We never delete any MDString until the context is destroyed. Might as
well throw them onto a BumpPtrAllocator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265520 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of copying arguments from the source function to the
destination, steal them. This has a few advantages.
- The ValueMap doesn't need to be seeded with (or cleared of)
Arguments.
- Often the destination function won't have created any arguments yet,
so this avoids malloc traffic.
- Argument names don't need to be copied.
Because argument lists are lazy, this required a new
Function::stealArgumentListFrom helper.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265519 91177308-0d34-0410-b5e6-96231b3b80d8
Fixed to adapt a use of enterBasicBlock() in my last commit (because I
had follow on patches in my repository that change the code).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265513 91177308-0d34-0410-b5e6-96231b3b80d8
Make it obvious that the argument cannot be nullptr.
Remove an unnecessary nullptr check in initRegState.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265511 91177308-0d34-0410-b5e6-96231b3b80d8
r265273 added Mapper::mapBlockAddress, which delays mapping a
blockaddress value until the function has a body. The condition was
backwards, and should be checking Function::empty instead of
GlobalValue::isDeclaration.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265508 91177308-0d34-0410-b5e6-96231b3b80d8
Instead of crashing, give a nice error. As a drive-by, fix the location
associated with the errors for unresolved metadata (the location was off
by one token).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265507 91177308-0d34-0410-b5e6-96231b3b80d8
This patch enable sibling call optimization on ppc64 ELFv1/ELFv2 abi, and
add a couple of test cases. This patch also passed llvm/clang bootstrap
test, and spec2006 build/run/result validation.
Original issue: https://llvm.org/bugs/show_bug.cgi?id=25617
Great thanks to Tom's (tjablin) help, he contributed a lot to this patch.
Thanks Hal and Kit's invaluable opinions!
Reviewers: hfinkel kbarton
http://reviews.llvm.org/D16315
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265506 91177308-0d34-0410-b5e6-96231b3b80d8
While preserving the return value for @llvm.experimental.deoptimize at
the IR level is useful during mid-level optimization, doing so at the
machine instruction level requires generating some extra code and a
return that is non-ideal. This change has LLVM lower
```
%val = call @llvm.experimental.deoptimize
ret %val
```
to effectively
```
call @__llvm_deoptimize()
unreachable
```
instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265502 91177308-0d34-0410-b5e6-96231b3b80d8
As part of the TRI argument of addRegBankCoverage we already have access to
the TargetRegisterClass through the ID of that register class.
Therefore, there is no point in needing a TargetRegisterClass instance,
the ID is enough to get to it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265487 91177308-0d34-0410-b5e6-96231b3b80d8
Don't emit a gc.result for a statepoint lowered from
@llvm.experimental.deoptimize since the call into __llvm_deoptimize is
effectively noreturn. Instead follow the corresponding gc.statepoint
with an "unreachable".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265485 91177308-0d34-0410-b5e6-96231b3b80d8
Bionic has a defined thread-local location for the stack protector
cookie. Emit a direct load instead of going through __stack_chk_guard.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265481 91177308-0d34-0410-b5e6-96231b3b80d8
Prior to this patch, CFLAA wouldn't tag arguments/globals properly if
it didn't find any "interesting" edges on them. This means that, if all
you do is store constants to a global or argument, we would never
actually treat it as a global/argument.
Test case:
define void @foo(i32* %A, i32* %B) #0 {
entry:
store i32 0, i32* %A, align 4
store i32 0, i32* %B, align 4
ret void
}
CFLAA would say that %A can't alias %B, because neither pointer was
used in an interesting way. This patch makes us note whether something
is an argument, global, ... regardless of how interesting CFLAA thinks
its uses are.
(For the record, using a value in an interesting way means loading
from it, using it in a GEP, ...)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265474 91177308-0d34-0410-b5e6-96231b3b80d8
targeting jobs.
Now, addRegBankCoverage also adds the subreg-classes not just the
sub-classes of the given register class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265469 91177308-0d34-0410-b5e6-96231b3b80d8
Add a common parent class for ConstantArray, ConstantVector, and
ConstantStruct called ConstantAggregate. These are the aggregate
subclasses of Constant that take operands.
This is mainly a cleanup, adding common `isa` target and removing
duplicated code. However, it also simplifies caching which constants
point transitively at `GlobalValue` (a possible future direction).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265466 91177308-0d34-0410-b5e6-96231b3b80d8
I can't remember if adding `= default` will make MSVC happy, or if I
have to spell this out. Let's try the cleaner version first.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265465 91177308-0d34-0410-b5e6-96231b3b80d8
Change the default constructor to create invalid object.
The target will have to properly initialize the register banks before
using them.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265460 91177308-0d34-0410-b5e6-96231b3b80d8
This commit completely rewrites Mapper::mapMetadata (the implementation
of llvm::MapMetadata) using an iterative algorithm. The guts of the new
algorithm are in MDNodeMapper::map, the entry function in a new class.
Previously, Mapper::mapMetadata performed a recursive exploration of the
graph with eager "just in case there's a reason" malloc traffic.
The new algorithm has these benefits:
- New nodes and temporaries are not created eagerly.
- Uniquing cycles are not duplicated (see new unit test).
- No recursion.
Given a node to map, it does this:
1. Use a worklist to perform a post-order traversal of the transitively
referenced unmapped nodes.
2. Track which nodes will change operands, and which will have new
addresses in the mapped scheme. Propagate the changes through the
POT until fixed point, to pick up uniquing cycles that need to
change.
3. Map all the distinct nodes without touching their operands. If
RF_MoveDistinctMetadata, they get mapped to themselves; otherwise,
they get mapped to clones.
4. Map the uniqued nodes (bottom-up), lazily creating temporaries for
forward references as needed.
5. Remap the operands of the distinct nodes.
Mehdi helped me out by profiling this with -flto=thin. On his workload
(importing/etc. for opt.cpp), MapMetadata sped up by 15%, contributed
about 50% less to persistent memory, and made about 100x fewer calls to
malloc. The speedup is less than I'd hoped. The profile mainly blames
DenseMap lookups; perhaps there's a way to reduce them (e.g., by
disallowing remapping of MDString).
It would be nice to break the strange remaining recursion on the Value
side: MapValue => materializeInitFor => RemapInstruction => MapValue. I
think we could do this by having materializeInitFor return a worklist of
things to be remapped.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265456 91177308-0d34-0410-b5e6-96231b3b80d8
We only generate LOCKed versions of add/sub when the result is unused.
It often happens that the result is used, but only by a comparison. We
can optimize those out by reusing EFLAGS, which lets us use the proper
instructions, instead of having to fallback to LXADD.
Instead of doing this as an MI peephole (as we do for the other
non-LOCKed (really, non-MR) forms), do it in ISel. It becomes quite
tricky later.
This also makes it eventually possible to stop expanding and/or/xor
if the only user is an icmp (also see D18141).
This uses the LOCK ISD opcodes added by r262244.
Differential Revision: http://reviews.llvm.org/D17633
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265450 91177308-0d34-0410-b5e6-96231b3b80d8
At IR level, the swifterror argument is an input argument with type
ErrorObject**. For targets that support swifterror, we want to optimize it
to behave as an inout value with type ErrorObject*; it will be passed in a
fixed physical register.
The main idea is to track the virtual registers for each swifterror value. We
define swifterror values as AllocaInsts with swifterror attribute or a function
argument with swifterror attribute.
In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before
handling the basic blocks.
When iterating over all basic blocks in RPO, before actually visiting the basic
block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when
there are multiple predecessors or to simply propagate them. There, we create a
virtual register for each swifterror value in the entry block. For predecessors
that are not yet visited, we create virtual registers to hold the swifterror
values at the end of the predecessor. The assignments are saved in
SwiftErrorWorklist and will be materialized at the end of visiting the basic
block.
When visiting a load from a swifterror value, we copy from the current virtual
register assignment. When visiting a store to a swifterror value, we create a
virtual register to hold the swifterror value and update SwiftErrorMap to
track the current virtual register assignment.
Differential Revision: http://reviews.llvm.org/D18108
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@265433 91177308-0d34-0410-b5e6-96231b3b80d8
