| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
DIEs.
These were called from distinct places and had significant distinct
behavior. No need to make that a dynamic check inside the function
rather than just having two functions (refactoring some common code into
a helper function to be called from the two separate functions).
llvm-svn: 207539
|
|
|
|
|
|
| |
'final' and leave 'virtual' on some methods that are marked virtual without overriding anything and have no obvious overrides themselves.
llvm-svn: 207511
|
|
|
|
|
|
|
|
|
|
|
| |
Seems at some point the intent was to emit fission ranges_base as unique
per CU but the code today emits ranges_base as the start of the ranges
section for all CUs being compiled and all the ranges_base relative
addresses are relative to that. So removing this dead code and leaving
the status quo until there's a reason to change it (perhaps something's
faster if it has distinct ranges for each CU).
llvm-svn: 207464
|
|
|
|
|
|
| |
Based on code review by Eric Christopher on r207323
llvm-svn: 207460
|
|
|
|
| |
llvm-svn: 207458
|
|
|
|
|
|
|
|
| |
(Clang doesn't warn here because it knows the string is benign - the
assert still checks what it's intended to - though putting the correct
parens does make clang-format format the code a little better)
llvm-svn: 207456
|
|
|
|
|
|
| |
Patch by Jan Vesely <jan.vesely@rutgers.edu>.
llvm-svn: 207455
|
|
|
|
| |
llvm-svn: 207452
|
|
|
|
|
|
|
|
|
| |
Since all 4 ctor calls in DwarfDebug just pass in a trivially
constructed DIE with the right tag type, sink the tag selection down
into the Dwarf*Unit ctors (removing the argument entirely from callers
in DwarfDebug) and initialize the DIE member in DwarfUnit.
llvm-svn: 207448
|
|
|
|
| |
llvm-svn: 207447
|
|
|
|
| |
llvm-svn: 207444
|
|
|
|
|
|
|
|
|
|
| |
Now that the subtle constructScopeDIE has been refactored into two
functions - one returning memory to take ownership of, one returning a
pointer to already owning memory - push unique_ptr through more APIs.
I think this completes most of the unique_ptr ownership of DIEs.
llvm-svn: 207442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While refactoring out constructScopeDIE into two functions I realized we
were emitting DW_AT_object_pointer in the inlined subroutine when we
didn't need to (GCC doesn't, and the abstract subprogram definition has
the information already).
So here's the refactoring and the bug fix. This is one step of
refactoring to remove some subtle memory ownership semantics. It turns
out the original constructScopeDIE returned ownership in its return
value in some cases and not in others. The split into two functions now
separates those two semantics - further cleanup (unique_ptr, etc) will
follow.
llvm-svn: 207441
|
|
|
|
| |
llvm-svn: 207397
|
|
|
|
| |
llvm-svn: 207394
|
|
|
|
|
|
| |
ArrayRef<SDValue>
llvm-svn: 207383
|
|
|
|
| |
llvm-svn: 207379
|
|
|
|
| |
llvm-svn: 207378
|
|
|
|
| |
llvm-svn: 207377
|
|
|
|
| |
llvm-svn: 207376
|
|
|
|
| |
llvm-svn: 207375
|
|
|
|
| |
llvm-svn: 207374
|
|
|
|
| |
llvm-svn: 207373
|
|
|
|
|
|
|
|
| |
default arguments to the function.
No functional change.
llvm-svn: 207372
|
|
|
|
|
|
|
| |
Includes a fix for a horrible typo that caused all SDIV costs to be
slightly off :)
llvm-svn: 207371
|
|
|
|
|
|
|
|
|
|
| |
AsmPrinter.
No functional change.
http://reviews.llvm.org/D3373
rdar://problem/15928306
llvm-svn: 207369
|
|
|
|
|
|
|
|
|
|
| |
entry. This is in preparation for generic DW_OP_piece support.
No functional change so far.
http://reviews.llvm.org/D3373
rdar://problem/15928306
llvm-svn: 207368
|
|
|
|
| |
llvm-svn: 207359
|
|
|
|
|
|
| |
constructed member.
llvm-svn: 207357
|
|
|
|
|
|
|
|
| |
(MCSymbol*)StrSym explicitly.
It will fix crash in codegen on msvc x64.
llvm-svn: 207356
|
|
|
|
| |
llvm-svn: 207352
|
|
|
|
| |
llvm-svn: 207338
|
|
|
|
| |
llvm-svn: 207334
|
|
|
|
|
|
|
|
| |
DW_AT_object_pointer to go missing on blocks
Noticed by inspection. Test coverage added.
llvm-svn: 207333
|
|
|
|
|
|
| |
and size.
llvm-svn: 207329
|
|
|
|
| |
llvm-svn: 207327
|
|
|
|
|
|
| |
these were calling makeVTList with the pointers passed in which would were unlikely to belong to SelectionDAG and likely would have just been stack pointers.
llvm-svn: 207326
|
|
|
|
|
|
|
|
|
|
|
|
| |
requires an address.
Since there's no way to ensure the type unit in the .dwo and the type
unit skeleton in the .o are correlated, this cannot work.
This implementation is a bit inefficient for a few reasons, called out
in comments.
llvm-svn: 207323
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sinking addition of the declaration attribute down to where the
signature is added. So that if the signature is not added neither is the
declaration attribute (this will come in handy when aborting type unit
construction to instead emit the type into the CU directly in some
cases)
Pull out type unit identifier hashing just to simplify the function a
little, it'll be getting longer.
llvm-svn: 207321
|
|
|
|
|
|
| |
DAGCombiner transform work on vectors.
llvm-svn: 207316
|
|
|
|
|
|
|
|
|
|
|
|
| |
Otherwise the legalizer would just scalarize everything. Support for
mulhi in the targets isn't that great yet so on most targets we get
exactly the same scalarized output. Add a test for x86 vector udiv.
I had to disable the mulhi nodes on ARM because there aren't any patterns
for it. As far as I know ARM has instructions for getting the high part of
a multiply so this should be fixed.
llvm-svn: 207315
|
|
|
|
| |
llvm-svn: 207313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The included test case would return the incorrect results, because the expansion
of an shift with a constant shift amount of 0 would generate undefined behavior.
This is because ExpandShiftByConstant assumes that all shifts by constants with
a value of 0 have already been optimized away. This doesn't happen for opaque
constants and usually this isn't a problem, because opaque constants won't take
this code path - they are not supposed to. In the case that the opaque constant
has to be expanded by the legalizer, the legalizer would drop the opaque flag.
In this case we hit the limitations of ExpandShiftByConstant and create incorrect
code.
This commit fixes the legalizer by not dropping the opaque flag when expanding
opaque constants and adding an assertion to ExpandShiftByConstant to catch this
not supported case in the future.
This fixes <rdar://problem/16718472>
llvm-svn: 207304
|
|
|
|
|
|
|
|
| |
low_pc similar to location lists.
Fixes PR19563
llvm-svn: 207283
|
|
|
|
|
|
|
|
|
|
| |
duplicate lookup.
This also avoids the need for subtly side-effecting calls to manifest
strings in the string table at the point where items are added to the
accelerator tables.
llvm-svn: 207281
|
|
|
|
|
|
|
|
|
| |
Pulls out some more code from some of the rather monolithic DWARF
classes. Unlike the address table, the string table won't move up into
DwarfDebug - each DWARF file has its own string table (but there can be
only one address table).
llvm-svn: 207277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildbot - do not insert debug intrinsics before phi nodes.
Debug info for optimized code: Support variables that are on the stack and
described by DBG_VALUEs during their lifetime.
Previously, when a variable was at a FrameIndex for any part of its
lifetime, this would shadow all other DBG_VALUEs and only a single
fbreg location would be emitted, which in fact is only valid for a small
range and not the entire lexical scope of the variable. The included
dbg-value-const-byref testcase demonstrates this.
This patch fixes this by
Local
- emitting dbg.value intrinsics for allocas that are passed by reference
- dropping all dbg.declares (they are now fully lowered to dbg.values)
SelectionDAG
- renamed constructors for SDDbgValue for better readability.
- fix UserValue::match() to handle indirect values correctly
- not inserting an MMI table entries for dbg.values that describe allocas.
- lowering dbg.values that describe allocas into *indirect* DBG_VALUEs.
CodeGenPrepare
- leaving dbg.values for an alloca were they are (see comment)
Other
- regenerated/updated instcombine.ll testcase and included source
rdar://problem/16679879
http://reviews.llvm.org/D3374
llvm-svn: 207269
|
|
|
|
| |
llvm-svn: 207264
|
|
|
|
|
|
|
|
|
|
|
| |
This should reduce the chance of memory leaks like those fixed in
r207240.
There's still some unclear ownership of DIEs happening in DwarfDebug.
Pushing unique_ptr and references through more APIs should help expose
the cases where ownership is a bit fuzzy.
llvm-svn: 207263
|
|
|
|
|
|
|
| |
Makes some more cases (the unit tests, specifically), lexically
compatible with a change to unique_ptr.
llvm-svn: 207261
|