When generating path notes, implicit function bodies are shown at the call
site, so that, say, copying a POD type in C++ doesn't jump you to a header
file. This is especially important when the synthesized function itself
calls another function (or block), in which case we should try to jump the
user around as little as possible.
By checking whether a called function has a body in the AST, we can tell
if the analyzer synthesized the body, and if we should therefore collapse
the call down to the call site like a true implicitly-defined function.
<rdar://problem/13978414>
llvm-svn: 182677
The new edge algorithm would keep track of the previous location in each
location context, so that it could draw arrows coming in and out of each
inlined call. However, it tried to access the location of the call before
it was actually set (at the CallEnter node). This only affected
unterminated calls at the end of a path; calls with visible exit nodes
already had a valid location.
This patch ditches the location context map, since we're processing the
nodes in order anyway, and just unconditionally updates the PrevLoc
variable after popping out of an inlined call.
<rdar://problem/13983470>
llvm-svn: 182676
To make this more consistent with 'getOrCreateType' & clarify the
distinction between the two. The only thing I couldn't quite communicate
in the name is that getOrCreateTypeDeclaration may actually produce a
full definition (in -fno-limit-debug-info) but the point is to call it
whenever only a declaration is needed & the implementation can choose
whether to provide a declaration or definition.
(also, unfortunately, getOrCreateType can produce declarations too - we
should sure this up by making it not do that - any caller that can
tolerate a declaration should be calling getOrCreateTypeDeclaration
instead)
llvm-svn: 182674
Perhaps we should just suppress this, rather than erroring, but since we
have the infrastructure for it I figured I'd use it - if this is
determined to be not the right thing we should probably remove that
infrastructure entirely. I guess it's lying around from the early days
of implementing debug info support.
llvm-svn: 182673
This removes a FIXME in CodeGenModule::SetLLVMFunctionAttributesForDefinition.
When a function is declared cold we can now generate the IR attribute in
addition to marking the function to be optimized for size.
I tried adding a separate CHECK in the existing test, but it was
failing. I suppose CHECK matches one line exactly once? This would be
a problem if the attributes are listed in a different order, though they
seem to be sorted.
llvm-svn: 182666
- Fix for attach by name
- Details for register support
- Punted on i386 details as its status has drifted since this page was originally posted
- Multi-threaded target support is soon to be released on Linux
- Partial back-trace is called out since its a high-profile issue
llvm-svn: 182664
In GDB when "step" through generateScalarLoad and "finish" the call, the
returned value is non NULL, however when printing the value contained in
BBMap[Load] after this stmt:
BBMap[Load] = generateScalarLoad(...);
the value in BBMap[Load] is NULL, and the BBMap.count(Load) is 1.
The only intuitive idea that I have to explain this behavior is that we are
playing with the undefined behavior of eval order of the params for the function
standing for "BBMap[Load] = generateScalarLoad()". "BBMap[Load] = " may be
executed before generateScalarLoad is called.
Here are some other possible explanations from Will Dietz <w@wdtz.org>:
The error is likely due to BBMap[Load] being evaluated first (creating
a {Load -> uninitialized } entry in the DenseMap), then
generateScalarLoad eventually accesses the same element and finds it
to be NULL (DenseMap[Old]).. Offhand I'm not sure if this is
guaranteed to be NULL or if it's uninitialized and happens to be NULL.
The same issue can also go wrong in an even worse way: the second
DenseMap access can trigger a rehash and *invalidate* the an earlier
evaluated expression (for example LHS of the assignment), leading to a
crash when performing the assignment store.
llvm-svn: 182655
Sanitizer runtime intercepts functions from librt. Not doing this will fail
if the librt dependency is not present at program startup (ex. comes from a
dlopen()ed library).
llvm-svn: 182645
Previously, an invalid instruction like:
foo %r1, %r0
would generate the rather odd error message:
....: error: unknown token in expression
foo %r1, %r0
^
We now get the more informative:
....: error: invalid instruction
foo %r1, %r0
^
The same would happen if an address were used where a register was expected.
We now get "invalid operand for instruction" instead.
llvm-svn: 182644
The idea is to make sure that:
(1) "register expected" is restricted to cases where ParseRegister()
is called and the token obviously isn't a register.
(2) "invalid register" is restricted to cases where a register-like "%..."
sequence is found, but the "..." makes no sense.
(3) the generic "invalid operand for instruction" is used in cases where
the wrong register type is used (GPR instead of FPR, etc.).
(4) the new "invalid register pair" is used if the register has the right type,
but is not a valid register pair.
Testing of (1)-(3) is now restricted to regs-bad.s. It uses a representative
instruction for each register class to make sure that only registers from
that class are accepted.
(4) is tested by both regs-bad.s (which checks all invalid register pairs)
and insn-bad.s (which tests one invalid pair for each instruction that
requires a pair).
While there, I changed "Number" to "Num" for consistency with the
operand class.
llvm-svn: 182643
as the BinaryOperator, *not* in the block where the IRBuilder is currently
inserting into. Fixes a bug where scalarizePHI would create instructions
that would not dominate all uses.
llvm-svn: 182639
Other than recognizing the attribute, the patch does little else.
It changes the branch probability analyzer so that edges into
blocks postdominated by a cold function are given low weight.
Added analysis and code generation tests. Added documentation for the
new attribute.
llvm-svn: 182638
We don't want to report initialization-order bugs when a destructor of a global
variable accesses dynamically initialized global from another
(not necessarily initialized) module. We do this by intercepting __cxa_atexit and
registrering our own callback that unpoisons shadow for all dynamically initialized
global variables.
llvm-svn: 182637
There was exactly one caller using this API right, the others were relying on
specific behavior of the default implementation. Since it's too hard to use it
right just remove it and standardize on the default behavior.
Defines away PR16132.
llvm-svn: 182636
In these builds, the asserts() are completely compiled out of the code
leaving "End" unused. Directly accessing it, should not have a
performance impact, as it is just a data member.
llvm-svn: 182634
Michael Gottesman