| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
get the entry frequency while processing data.
llvm-svn: 197291
|
| |
|
|
|
|
| |
MachineBlockFrequencyInfo methods.
llvm-svn: 197290
|
| |
|
|
|
|
| |
new print methods.
llvm-svn: 197289
|
| |
|
|
| |
llvm-svn: 197288
|
| |
|
|
|
|
| |
BlockFrequencyInfo that were added to BlockFrequencyImpl in r197285 and r197284.
llvm-svn: 197287
|
| |
|
|
|
|
| |
functionality from r197285.
llvm-svn: 197286
|
| |
|
|
|
|
|
|
|
|
|
|
| |
frequencies and a convenience method for the common case of getting/printing a basic block.
BlockFrequencies can only be printed relative to their entry frequency. Thus
since the entry frequency is no longer necessarily a static constant on the
BlockFrequency class and is instead a potentially dynamic value taken from
BlockFrequencyImpl, we must necessarily print it via a method on
BlockFrequencyImpl.
llvm-svn: 197285
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
BlockFrequencyImpl::EntryFreq.
This is a property associated with a function, not with BlockFrequency data.
Additionally it loosens the artifical requirement that the entry frequency
arbitrarily be the same for every function.
There is a series of patches forthcoming updating various code that uses the old
way of getting a block frequency to the new location.
llvm-svn: 197284
|
| |
|
|
|
|
| |
Also update for the current naming style.
llvm-svn: 197283
|
| |
|
|
|
|
|
|
|
|
|
| |
were falling into the cases for 24-bit branch kinds which are not 24-bit
branches. The routine is to return false for fixups are expected to always
be resolvable at assembly time. Which these three fixups are as they have
limited displacement and are for local references within a function.
rdar://15586725
llvm-svn: 197282
|
| |
|
|
| |
llvm-svn: 197281
|
| |
|
|
| |
llvm-svn: 197280
|
| |
|
|
| |
llvm-svn: 197279
|
| |
|
|
| |
llvm-svn: 197278
|
| |
|
|
|
|
| |
Change tests for extractBit to test operator[].
llvm-svn: 197277
|
| |
|
|
| |
llvm-svn: 197276
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
comdat grouping and type unit headers
This commit does not complete the type units feature - there are issues
around fission support (skeletal type units, pubtypes/pubnames) and
hashing of some types including those containing references to types in
other type units.
Originally committed as r197073 and reverted in r197079.
Recommitted as r197197 to reproduce the failure and reverted as r197199
Turns out there was unstable ordering in the type unit dumping code.
Fixed by using MapVector in DWARFContext to store the debug_types
comdat sections.
Recommitted as r197210 with a fix to dumping and reverted as r197211
because I was a bit gun shy and thought I saw a failure that turned out
to be unrelated.
So here we go - once more with feeling! \o/
llvm-svn: 197275
|
| |
|
|
| |
llvm-svn: 197274
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's nothing special about type traits accepting two arguments.
This commit eliminates BinaryTypeTraitExpr and switches all related handling
over to TypeTraitExpr.
Also fixes a CodeGen failure with variadic type traits appearing in a
non-constant expression.
The BTT/TT prefix and evaluation code is retained as-is for now but will soon
be further cleaned up.
This is part of the ongoing work to unify type traits.
llvm-svn: 197273
|
| |
|
|
| |
llvm-svn: 197272
|
| |
|
|
| |
llvm-svn: 197271
|
| |
|
|
| |
llvm-svn: 197270
|
| |
|
|
| |
llvm-svn: 197269
|
| |
|
|
| |
llvm-svn: 197268
|
| |
|
|
| |
llvm-svn: 197267
|
| |
|
|
|
|
| |
and remote targets.
llvm-svn: 197266
|
| |
|
|
| |
llvm-svn: 197265
|
| |
|
|
|
|
| |
"lldb/API/SB*" and "lldb/lldb*" headers.
llvm-svn: 197264
|
| |
|
|
|
|
| |
// rdar://15641300
llvm-svn: 197263
|
| |
|
|
|
|
|
|
|
|
| |
just register units."
This reverts commit r197253.
This was a great change, but Juergen should be the commit author.
llvm-svn: 197262
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r197254.
This was an accidental merge of Juergen's patch. It will be checked in
shortly, but wasn't meant to go in quite yet.
Conflicts:
include/llvm/CodeGen/StackMaps.h
lib/CodeGen/StackMaps.cpp
test/CodeGen/X86/stackmap-liveness.ll
llvm-svn: 197260
|
| |
|
|
|
|
| |
They are equivalent and the size of 'a' and 's' is unused.
llvm-svn: 197259
|
| |
|
|
|
|
| |
They are equivalent and the size of 'a' and 's' is unused.
llvm-svn: 197256
|
| |
|
|
| |
llvm-svn: 197255
|
| |
|
|
| |
llvm-svn: 197254
|
| |
|
|
|
|
| |
register units.
llvm-svn: 197253
|
| |
|
|
|
|
|
|
|
|
|
| |
The tests were perhaps made too relaxed in r197164 when we switched to the new
MinGW ABI. This makes sure we check explicitly for an optional thiscall
attribute and nothing else.
We should still look into whether we should print these attributes at all in
these cases.
llvm-svn: 197252
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
property declaration has a memory management
attribute (retain, copy, etc.). Sich properties
are usually overridden to become 'readwrite'
via a class extension (which require the memory
management attribute specified). In the absence of class
extension override, memory management attribute is
needed to produce correct Code Gen. for the
property getter in any case and this warning becomes
confusing to user. // rdar://15641300
llvm-svn: 197251
|
| |
|
|
|
|
|
|
|
| |
step, floating-point reciprocal square root step, floating-point absolute
difference, and integer/floating-point compare instructions. Also, move the
scalar general arithmetic operation patterns closer to similar code. No
functional change intended.
llvm-svn: 197250
|
| |
|
|
| |
llvm-svn: 197249
|
| |
|
|
| |
llvm-svn: 197248
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
While investigating test suite failures when running the test suite remotely, I noticed we had 3 copies of code that launched a process:
1 - in "process launch" command
2 - SBTarget::Launch() with args
3 - SBTarget::Launch() with SBLaunchInfo
"process launch" was launching through the platform if it was supported (this is needed for remote debugging) and the 2 and 3 were not.
Now all code is in one place.
llvm-svn: 197247
|
| |
|
|
|
|
|
|
|
| |
-analyzer-config options are now passed from scan-build through to
ccc-analyzer and then to clang.
Patch by Daniel Connelly!
llvm-svn: 197246
|
| |
|
|
|
|
| |
Raw lexers don't have a preprocessor so we need to null check.
llvm-svn: 197245
|
| |
|
|
| |
llvm-svn: 197244
|
| |
|
|
|
|
|
|
| |
are used on non-kernel functions.
Reviewed by Aaron over IRC!
llvm-svn: 197243
|
| |
|
|
| |
llvm-svn: 197242
|
| |
|
|
|
|
|
|
|
|
| |
The cpp backend is not a reasonable fallback for a missing target. It is a
very special backend, so it is reasonable to use it only if explicitly
requested.
While at it, simplify the interface a bit.
llvm-svn: 197241
|
| |
|
|
|
|
|
|
|
| |
Well, that's one way to pass a test, I suppose. Unfortunately actually doing
the testing means I didn't pass all I thought (embedded v7a is not supported,
apparently). I'll deal with that with the move to -none-macho rather than
putting heinous hacks in right now.
llvm-svn: 197240
|
| |
|
|
|
|
|
| |
In those cases it's better to compare the result of the subtraction
against zero.
llvm-svn: 197239
|