Summary:
The correct spelling is "DWARF", the debugging format, not "DWARG".
The typo is in a (not executed by lit) comment in a test file, so
fixing it does not result in any functional change.
Test Plan: check-llvm, just in case
llvm-svn: 332878
Rather than relying on the user to do the address calculating in
DW_AT_location we should just dump the absolute address.
rdar://problem/38513870
Differential revision: https://reviews.llvm.org/D47152
llvm-svn: 332873
This class will be used to create regular, non-split ELF files.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47049
llvm-svn: 332870
With this we gain a little flexibility in how the generic object
writer is created.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47045
llvm-svn: 332868
Change matchSelectPattern to return X and -X for ABS/NABS in a well defined order. Adjust EarlyCSE to account for this. Ensure the SPF result is some kind of min/max and not abs/nabs in one place in InstCombine that made me nervous.
Prevously we returned the two operands of the compare part of the abs pattern. The RHS is always going to be a 0i, 1 or -1 constant. This isn't a very meaningful thing to return for any one. There's also some freedom in the abs pattern as to what happens when the value is equal to 0. This freedom led to early cse failing to match when different constants were used in otherwise equivalent operations. By returning the input and its negation in a defined order we can ensure an exact match. This also makes sure both patterns use the exact same subtract instruction for the negation. I believe CSE should evebntually make this happen and properly merge the nsw/nuw flags. But I'm not familiar with CSE and what order it does things in so it seemed like it might be good to really enforce that they were the same.
Differential Revision: https://reviews.llvm.org/D47037
llvm-svn: 332865
AMDGPUDAGToDAGISel adds DivergenceAnalysis in getAnalysisUsage
but does not list it in pass dependencies which may lead to
crash.
Differential Revision: https://reviews.llvm.org/D47151
llvm-svn: 332862
r332654 was reverted due to an unused function warning in
release build. This commit includes the same code with the
warning silenced.
Differential Revision: https://reviews.llvm.org/D44338
llvm-svn: 332860
Also clean up a couple of hacks where we were writing the section
contents to another stream by setting the object writer's stream,
writing and setting it back.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47038
llvm-svn: 332858
To make this work I needed to add an endianness field to MCAsmBackend
so that writeNopData() implementations know which endianness to use.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47035
llvm-svn: 332857
Summary:
This patch fixes PR37526 by simplifying the newly generated LoadInst
instructions. If the pointer address is a bitcast from the pointer to
the NewType, we can just remove this extra bitcast instead of creating
the new one. This fixes the PR37526 + may speed up the whole compilation
process.
Reviewers: spatel, RKSimon, hfinkel
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D47144
llvm-svn: 332855
Fix internal build failure:
../../../ClangDiagnosticsEmitter.cpp -o ClangDiagnosticsEmitter.o
../../../ClangDiagnosticsEmitter.cpp: In function 'llvm::StringRef
{anonymous}::getModifierName({anonymous}::ModifierType)':
../../../ClangDiagnosticsEmitter.cpp:495:1: error: control reaches end of non-void function [-Werror=return-type]
}
^
Build failure triggered by git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@332799 91177308-0d34-0410-b5e6-96231b3b80d8
Differential Revision: https://reviews.llvm.org/D47150
llvm-svn: 332854
if `-fopenmp-simd` is specified alone, `_OPENMP` macro should not be
defined. If `-fopenmp-simd` is specified along with the `-fopenmp`,
`_OPENMP` macro should be defined with the value `201511`.
llvm-svn: 332852
Summary: Add LLVMDIBuilderCreateObjCIVar, LLVMDIBuilderCreateObjCProperty, and LLVMDIBuilderCreateInheritance to allow declaring metadata for Objective-C class hierarchies and their associated properties and instance variables.
Reviewers: whitequark, deadalnix
Reviewed By: whitequark
Subscribers: harlanhaskins, llvm-commits
Differential Revision: https://reviews.llvm.org/D47123
llvm-svn: 332850
1. added restrictions to memory scope, order and volatile parameters
2. added custom processing for these builtins - currently is not used code,
needed to switch off GCCBuiltin link to the builtins (ongoing change to llvm
tree)
3. builtins renamed as requested
Differential Revision: https://reviews.llvm.org/D43281
llvm-svn: 332848
If a variable has an initializer, codegen tries to build its value. If
the variable is large in size, building its value requires substantial
resources. It causes strange behavior from user viewpoint: compilation
of huge zero initialized arrays like:
char data_1[2147483648u] = { 0 };
consumes enormous amount of time and memory.
With this change codegen tries to determine if variable initializer is
equivalent to zero initializer. In this case variable value is not
constructed.
This change fixes PR18978.
Differential Revision: https://reviews.llvm.org/D46241
llvm-svn: 332847
Change the "recoverable" error callback to take an Error instaed of a
string.
Reviewed by: JDevlieghere
Differential Revision: https://reviews.llvm.org/D46831
llvm-svn: 332845
Handle attributes before checking the record layout (e.g. underalignment check
during `alignas` processing), as layout may be cached without taking into
account attributes that may affect it.
Differential Revision: https://reviews.llvm.org/D46439
llvm-svn: 332843
PathMappingList was broken for relative and empty paths after normalization changes in FileSpec. There were also no tests for PathMappingList so I added those.
Changes include:
Change PathMappingList::ReverseRemapPath() to take FileSpec objects instead of ConstString. The only client of this was doing work to convert to and from ConstString objects for no reason.
Normalize all paths prefix and replacements that are added to the PathMappingList vector so they match the paths that have been already normalized in the debug info
Unify code in the two forms of PathMappingList::RemapPath() so only one contains the actual functionality. Prior to this, there were two versions of this code.
Use FileSpec::AppendPathComponent() and remove a long standing TODO so paths are correctly appended to each other.
Added tests for absolute, relative and empty paths.
Differential Revision: https://reviews.llvm.org/D47021
llvm-svn: 332842
Chances are we'll be asked again after type legalization, but before that point
it's better to claim misaligned accesses aren't allowed than to assert.
llvm-svn: 332840
The first version of the patch (r332228) was flawed because it was
putting structors into C5/D5 comdats very eagerly. This is correct only
if we can ensure the comdat contains all required versions of the
structor (which wasn't the case). This version uses a more nuanced
approach:
- for local structor symbols we use an alias because we don't have to
worry about comdats or other compilation units.
- linkonce symbols are emitted separately, as we cannot guarantee we
will have all symbols we need to form a comdat (they are emitted
lazily, only when referenced).
- available_externally symbols are also emitted separately, as the code
seemed to be worried about emitting an alias in this case.
- other linkage types are not affected by the optimization level. They
either get put into a comdat (weak) or get aliased (external).
Reviewers: rjmccall, aprantl
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D46685
llvm-svn: 332839
We were previously using a DT in CVP through SimplifyQuery, but not requiring it in
the new pass manager. Hence it would crash if DT was not already available. This now
gets DT directly and plumbs it through to where it is used (instead of using it
through SQ).
llvm-svn: 332836
MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass
because of mutual conflict. When MipsHazardSchedule inserts 'nop's, it
potentially breaks some jumps, so they have to be expanded to long
branches. When some branch is expanded to long branch, it potentially
creates a hazard situation, which should be fixed by adding nops.
New pass is called MipsBranchExpansion, it combines these two passes,
and runs them alternately until one of them reports no changes were made.
Differential Revision: https://reviews.llvm.org/D46641
llvm-svn: 332834
After closer examination, it turns out we mis-classify one of the
methods only if two of the structs have the same name. Since this was
meant to be a basic test, I rename one of the structs in the test so
that we have at least some coverage for the apple tables lookup.
Instead, I create an XFAILed test which specifically targets the
same-name case (and file a bug to track it).
llvm-svn: 332833
As suggested by Fabian on PR37426, we can use PMULUDQ to perform v4i32 vector rotations as the upper 32bits of the multiply will contain the 'wrapped' bits of the rotation.
v8i16/v16i8 rotations would be straightforward to add to lowerRotate in the future - ideally we'd mostly share code with the vector shifts lowering.
Differential Revision: https://reviews.llvm.org/D46954
llvm-svn: 332832
Summary:
Now that we are able to parse MachO files everywhere, we can write some
cross-platform tests for handling of apple accelerator tables. This
reruns the same lookup tests we have for manual indexes on MachO files
which will use the accelerator tables instead. This makes sure we return
the same results regardless of the method we used to access the debug
info.
The tests confirm we return the same results for looking up types,
namespaces and variables, but have found an inconsistency in the
treatment of function lookup. In the function case we mis-classify the
method "foo" declared in the local struct sbar (inside function ffbar).
We classify it as a function whereas it really is a method. Preliminary
analysis suggests this is because
DWARFASTParserClang::GetClangDeclContextForDIE returns null when given
the local "struct sbar" DIE. This causes us to get the wrong
CompilerDeclContext when we ask for the context of the inner foo, which
means CompilerDeclContext::ISStructUnionOrClass returns false.
Until this is fixed, I do not include the darwin versions of the "base"
and "method" function lookup tests.
Reviewers: JDevlieghere, clayborg
Subscribers: aprantl, ilya-biryukov, ioeric, lldb-commits
Differential Revision: https://reviews.llvm.org/D47064
llvm-svn: 332831
Reid Kleckner