| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 209040
|
|
|
|
|
|
| |
contains declarations.
llvm-svn: 209039
|
|
|
|
|
|
|
|
| |
Patch by Stephan Tolksdorf! (with some test case stuff by me)
Differential Revision: http://reviews.llvm.org/D3810
llvm-svn: 209037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to put dynamic initializers for weak data into the same
comdat group as the data being initialized. This is necessary for MSVC
ABI compatibility. Once we have comdats for guard variables, we can use
the combination to help GlobalOpt fire more often for weak data with
guarded initialization on other platforms.
Reviewers: nlewycky
Differential Revision: http://reviews.llvm.org/D3499
llvm-svn: 209015
|
|
|
|
|
|
|
|
|
|
| |
matching the abstract subprogram.
I'm not sure this is how it'll be going forward (I'd rather prefer the
definition to be in the main SP mapping, for various reasons) but this
helps me understand how it is today.
llvm-svn: 209009
|
|
|
|
|
|
|
|
|
|
|
| |
DIBuilder maintains this invariant and the current DwarfDebug code could
end up doing weird things if it contained declarations (such as putting
the definition DIE inside a CU that contained the declaration - this
doesn't seem like a good idea, so rather than adding logic to handle
this case we'll just ban in for now & cross that bridge if we come to
it later).
llvm-svn: 209004
|
|
|
|
|
|
| |
function.
llvm-svn: 208997
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r208934.
The patch depends on aliases to GEPs with non zero offsets. That is not
supported and fairly broken.
The good news is that GlobalAlias is being redesigned and will have support
for offsets, so this patch should be a nice match for it.
llvm-svn: 208978
|
|
|
|
| |
llvm-svn: 208937
|
|
|
|
|
|
|
|
|
|
|
| |
This commit implements two command line switches -global-merge-on-external
and -global-merge-aligned, and both of them are false by default, so this
optimization is disabled by default for all targets.
For ARM64, some back-end behaviors need to be tuned to get this optimization
further enabled.
llvm-svn: 208934
|
|
|
|
|
|
|
|
| |
class overload.
Code review feedback from Eric Christopher.
llvm-svn: 208933
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 208932
|
|
|
|
|
|
|
|
|
| |
Since type units in the dwo file are handled by a debug aware tool, they
don't need to leverage the ELF comdat grouping to implement
deduplication. Avoid creating all the .group sections for these as a
space optimization.
llvm-svn: 208930
|
|
|
|
|
|
| |
building.
llvm-svn: 208911
|
|
|
|
|
|
|
| |
computeKnownBits, consolidate them into one assert at the end of
computeKnownBits itself.
llvm-svn: 208876
|
|
|
|
| |
llvm-svn: 208839
|
|
|
|
|
|
|
|
| |
Abstract variables should never have/use locations. In this case the
data wasn't used, so no functional change intended here, just
simplification.
llvm-svn: 208820
|
|
|
|
|
|
|
|
|
|
|
|
| |
and fewer conditionals.
Many old tests using prior schemas still had some brokenness here (both
indirect arrays and arrays with single bogus elements). Fixed those up
so they don't hit the new assertions.
Also reduced nesting in some places, etc.
llvm-svn: 208817
|
|
|
|
| |
llvm-svn: 208816
|
|
|
|
|
|
| |
inappropriate since it lost its Mask parameter in r154011.
llvm-svn: 208811
|
|
|
|
|
|
|
|
|
|
| |
definitions.
This is just unneccessary - we only create abstract definitions when
we're inlining anyway, so there's no reason to delay this to see if
we're going to inline anything.
llvm-svn: 208798
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the function has the landingpad instruction, then the
handlerdata should be emitted even if the function has
nouwnind attribute. Otherwise, following code will not
work:
void test1() noexcept {
try {
throw_exception();
} catch (...) {
log_unexpected_exception();
}
}
Since the cantunwind was incorrectly emitted and the
LSDA is not available.
llvm-svn: 208791
|
|
|
|
|
|
| |
in r154011.
llvm-svn: 208757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was reverted in r208642 due to regressions surrounding file changes
within lexical scopes causing inlining information to be lost.
The issue was in LexicalScopes::getOrCreateInlinedScope, where I was
previously testing "isLexicalBlock" which is false for
"DILexicalBlockFile" (a scope used to represent changes in the current
file name) and assuming it was then a function (breaking out of the
inlined scope path and reaching for the parent non-inlined scopes). By
inverting the condition and testing for "isSubprogram" the correct
behavior is attained.
(also found some weirdness in Clang, see r208742 when reducing this test
case - the resulting test case doesn't apply with the Clang fix, but
I've added a more realistic test case to inline-scopes.ll which does
reproduce the issue and demonstrate the fix)
llvm-svn: 208748
|
|
|
|
| |
llvm-svn: 208731
|
|
|
|
|
|
|
|
|
| |
This allows code to statically accept a Function or a GlobalVariable, but
not an alias. This is already a cleanup by itself IMHO, but the main
reason for it is that it gives a lot more confidence that the refactoring to fix
the design of GlobalAlias is correct. That will be a followup patch.
llvm-svn: 208716
|
|
|
|
|
|
|
|
|
|
|
| |
compared to 'AddrMode.BaseReg'. In the case that 'AddrMode.BaseReg' is
nullptr, 'Result' will also be nullptr, so the cast causes an assertion. We
should use dyn_cast_or_null here to check 'Result' is not null and it is an
instruction.
Bug found by Mats Petersson, and I reduced his IR to get a test case.
llvm-svn: 208705
|
|
|
|
|
|
|
|
|
| |
This reverts commit r208506.
Some inlined subroutine scopes appear to be missing with this change.
Reverting while I investigate.
llvm-svn: 208642
|
|
|
|
|
|
|
|
|
|
|
|
| |
any targets so I couldn't find a test case to trigger it.
The problem occurs when a non-i1 setcc is inverted. For example 'i8 = setcc' will get 'xor 0xff' to invert this. This is clearly wrong when the boolean contents are ZeroOrOne.
This patch introduces getLogicalNOT and updates SetCC legalisation to use it.
Reviewed by Hal Finkel.
llvm-svn: 208641
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Right now the load may not get DCE'd because of the side-effect of updating
the base pointer.
This can happen if we lower a read-modify-write of an illegal larger type
(e.g. i48) such that the modification only affects one of the subparts (the
lower i32 part but not the higher i16 part). See the testcase.
In order to spot the dead load we need to revisit it when SimplifyDemandedBits
decided that the value of the load is masked off. This is the
CommitTargetLoweringOpt piece.
I checked compile time with ARM64 by sending SPEC bitcode files through llc.
No measurable change.
Fixes <rdar://problem/16031651>
llvm-svn: 208640
|
|
|
|
|
|
| |
time rather than as a post-processing step.
llvm-svn: 208636
|
|
|
|
|
|
|
|
|
|
| |
and reduce nesting/conditionals.
One test case had to be updated as it still had the extra indirection
for the variable list - removing the extra indirection got it back to
passing.
llvm-svn: 208608
|
|
|
|
| |
llvm-svn: 208598
|
|
|
|
|
|
| |
Add missing parenthesis suggested by GCC. NFC.
llvm-svn: 208519
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We must validate the value type in TLI::getRegisterByName, because if we
don't and the wrong type was used with the IR intrinsic, then we'll assert
(because we won't be able to find a valid register class with which to
construct the requested copy operation). For PPC64, additionally, the type
information is necessary to decide between the 64-bit register and the 32-bit
subregister.
No functionality change.
llvm-svn: 208508
|
|
|
|
| |
llvm-svn: 208506
|
|
|
|
|
|
|
|
| |
Filed as PR19712, LLVM fails to detect the right type of an enum
constant when a frontend does not provide an underlying type for the
enumeration type.
llvm-svn: 208502
|
|
|
|
|
|
|
|
|
| |
And the winner by a nose is isUnsignedDIType, for no particular reason.
These two functions were just complements of each other and used in very
related code, so refactor callers to just use one of them.
llvm-svn: 208500
|
|
|
|
|
|
| |
each caller of emitConstantValue doesn't have to call it separately.
llvm-svn: 208496
|
|
|
|
|
|
|
|
|
|
|
|
| |
64 bit) and MCOperand immediates.
Doesn't seem a good reason to duplicate this code (it was more literally
duplicated prior to r208494, and while the dataN code /does/ actually
fire in this case, it doesn't seem necessary (and the DWARF standard
recommends using udata/sdata pervasively instead of dataN, so as to
indicate signedness of the values))
llvm-svn: 208495
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code looks to have become dead at some time in the past. I tried to
reproduce cases where LLVM would emit constants with dataN, but could
not. Upon inspection it seems the code doesn't do that anymore - the
only time a size is provided by isTypeSigned is when the type is signed,
and in those cases we use sdata. dataN is only used for unsigned types
and isTypeSigned doesn't provide a value for sizeInBits in that case.
Remove the dead cases/size plumbing.
llvm-svn: 208494
|
|
|
|
|
|
|
|
|
|
| |
When using the ARM AAPCS, HFAs (Homogeneous Floating-point Aggregates) must
be passed in a block of consecutive floating-point registers, or on the stack.
This means that unused floating-point registers cannot be back-filled with
part of an HFA, however this can currently happen. This patch, along with the
corresponding clang patch (http://reviews.llvm.org/D3083) prevents this.
llvm-svn: 208413
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
comment of the API.
Relaxes the behavior of TargetInstrInfo::commuteInstruction when
TargetInstrInfo::findCommutedOpIndices returns false.
Previously TargetInstrInfo triggered a fatal error in such situation whereas based
on the comment in the API it should just return nullptr. Indeed the only
precondition that should be ensured is that the instruction must be commutable.
llvm-svn: 208371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
workaround for an MSVC2012 bug regarding forward_as_tuple
(r207876 was reverted in r208131 after seeing some consistent buildbot
failure for MSVC 2012. The original commits were in r207724-r207726)
Takumi was nice enough to dig into this and locate this Microsoft
Connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/814899/forward-as-tuple-debug-implementation-error
describing a bug in MSVC2012's forward_as_tuple implementation.
Since the parameters in this instance are trivial/small, pass them by
value (using make_tuple) instead of perfectly-forwarded tuple of rvalue
references (involving the broken forward_as_tuple). Hopefully this will
satisfy MSVC2012.
llvm-svn: 208364
|
|
|
|
| |
llvm-svn: 208314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old method used by X86TTI to determine partial-unrolling thresholds was
messy (because it worked by testing target features), and also would not
correctly identify the target CPU if certain target features were disabled.
After some discussions on IRC with Chandler et al., it was decided that the
processor scheduling models were the right containers for this information
(because it is often tied to special uop dispatch-buffer sizes).
This does represent a small functionality change:
- For generic x86-64 (which uses the SB model and, thus, will get some
unrolling).
- For AMD cores (because they still currently use the SB scheduling model)
- For Haswell (based on benchmarking by Louis Gerbarg, it was decided to bump
the default threshold to 50; we're working on a test case for this).
Otherwise, nothing has changed for any other targets. The logic, however, has
been moved into BasicTTI, so other targets may now also opt-in to this
functionality simply by setting LoopMicroOpBufferSize in their processor
model definitions.
llvm-svn: 208289
|
|
|
|
|
|
|
|
|
|
|
| |
When reducing the bitwidth of a comparison against a constant, the
original setcc's result type was used, which was incorrect.
No test since I don't think any other in tree targets change the
bitwidth of the setcc type depending on the bitwidth of the compared
type.
llvm-svn: 208236
|
|
|
|
|
|
| |
We were already always passing true, this just removes the option.
llvm-svn: 208205
|
|
|
|
|
|
|
|
|
| |
1) Fix for printing debug locations for absolute paths.
2) Location printing is moved into public method DebugLoc::print() to avoid re-inventing the wheel.
Differential Revision: http://reviews.llvm.org/D3513
llvm-svn: 208177
|
|
|
|
|
|
|
|
|
| |
Speculatively reverting due to a suspicious failure on a Windows
buildbot.
This reverts commit 10c37a012ea11596d44cd9059fe09c959caf30c8.
llvm-svn: 208131
|