This test sets the compiler optimization level to -O1 and
makes some assumptions about how local frame vars will be
stored (i.e. in registers). These assumptions are not always
true.
I did a first-pass set of improvements that:
(1) no longer assumes that every one of the target locations has
every variable in a register. Sometimes the compiler
is even smarter and skips the register entirely.
(2) simply expects one of the 5 or so variables it checks
to be in a register.
This test probably passes on a whole lot more systems than it
used to now. This is certainly true on OS X.
llvm-svn: 265498
Summary:
This bug was introduced by http://reviews.llvm.org/rL265059,
where InputSectionBase got Thunks field, which can do memory allocations.
Since InputSectionBase destructors were never called (I count it as another bug),
that caused a memory leak when 2 or more thunks are added to a section.
The fix to is properly call InputSectionBase destructors from ~ObjectFile.
Reviewers: atanasyan, ruiu, rafael
Subscribers: rafael, krasin, pcc
Differential Revision: http://reviews.llvm.org/D18809
llvm-svn: 265497
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.
llvm-svn: 265487
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".
llvm-svn: 265485
Bionic has a defined thread-local location for the stack protector
cookie. Emit a direct load instead of going through __stack_chk_guard.
llvm-svn: 265481
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, ...)
llvm-svn: 265474
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=25561 which was a
crash on invalid. Change the handling of invalid decls to have a catch-all
case to prevent unexpecting decls from triggering an assertion.
llvm-svn: 265467
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).
llvm-svn: 265466
While trying to get PIE work on CloudABI for x86-64, I noticed that even
though GNU ld would generate functional binaries, LLD would not. It
turns out that we generate relocations for referencing TLS objects
inside of the text segment, which shouldn't happen.
This change extends the isRelRelative() function to list some additional
relocation types that should be treated as relative. This makes my C
library unit testing binary work on x86-64.
Approved by: ruiu
Differential Revision: http://reviews.llvm.org/D18688
Fixes bug: https://llvm.org/bugs/show_bug.cgi?id=27174
llvm-svn: 265462
Change the default constructor to create invalid object.
The target will have to properly initialize the register banks before
using them.
llvm-svn: 265460
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.
llvm-svn: 265456
Some Include What You Use suggestions were used too.
Use anonymous namespaces in source files.
Differential revision: http://reviews.llvm.org/D18778
llvm-svn: 265454
Where Clang's AArch64 backend seems to differ from the X86 backend is
that it tends to use the GOT more aggressively.
After getting CloudABI PIEs working on x86-64, I noticed that accessing
global variables would still crash on aarch64. Tracing it down, it turns
out that the GOT was filled with entries assuming the base address was
zero.
It turns out that we skip generating relocations for GOT entries in case
the relocation pointing towards the GOT is relative. Whether the thing
pointing to the GOT is absolute or relative shouldn't make any
difference; the GOT entry itself should contain the absolute address,
thus needs a relocation regardless.
Approved by: rafael
Differential Revision: http://reviews.llvm.org/D18739
llvm-svn: 265453
To start with, handle DW_FORM_string names. Follow up commit will handle
the interesting quirk with type units I was originally aiming for here.
llvm-svn: 265452
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
llvm-svn: 265450
Todd Fiala