Changed the dwarf aranges code to not use getLabelEndName, as it turns out it's not reliable to call that given user-defined section names. Section names can have characters in that aren't representable as symbol names.
The dwarf-aranges test case has been updated to include a special character, to check this.
This fixes pr17416.
llvm-svn: 191932
DIE::addChild had a shortcircuit that silently no-op'd when a child was
readded to the same parent. This hid some quirky/redundant code in
DwarfDebug/CompileUnit. By removing that functionality and replacing it
with an assert I was able to find and cleanup those cases, mostly
centering around adding members to types in various circumstances.
1) The original oddity I noticed while working on type units (which
actually was helping me in the short term, by accident) was the
addToContextOwner call in constructTypeDIE. This call was completely
bogus (why was it only done for non-virtual types? what relevance does
that have at all) and redundant with the more uniform addToContextOwner
made in getOrCreateTypeDIE.
2) If a member function definition was visited (createSubprogramDIE), it
would attempt to build the member function declaration. The declaration
DIE would then be added to its context, but in building the context (the
type for which this function is a member) the members of the type would
be added to the type automatically, so by the time the context was
constructed, the member function was already associated with it.
3) The same as (2) but without the member function being constructed
first. Whenever a type was constructed, the members would be created and
member functions would be created by getOrCreateSubprogramDIE - this
would lead to the subprogram being added to the (incomplete) type
already, then the general member-construction code would add it again.
llvm-svn: 191928
r191052 added emitting .debug_aranges to Clang, but this
functionality is broken: it uses all MC labels added in DWARF Asm
printer, including the labels for build relocations between
different DWARF sections, like .Lsection_line or .Ldebug_loc0.
As a result, if any DIE .debug_info would contain "DW_AT_location=0x123"
attribute, .debug_aranges would also contain a range starting from 0x123,
breaking tools that rely on this section.
This patch fixes this by using only MC labels that corresponds to the
addresses in the user program.
llvm-svn: 191884
infrastructure.
This was essentially work toward PGO based on a design that had several
flaws, partially dating from a time when LLVM had a different
architecture, and with an effort to modernize it abandoned without being
completed. Since then, it has bitrotted for several years further. The
result is nearly unusable, and isn't helping any of the modern PGO
efforts. Instead, it is getting in the way, adding confusion about PGO
in LLVM and distracting everyone with maintenance on essentially dead
code. Removing it paves the way for modern efforts around PGO.
Among other effects, this removes the last of the runtime libraries from
LLVM. Those are being developed in the separate 'compiler-rt' project
now, with somewhat different licensing specifically more approriate for
runtimes.
llvm-svn: 191835
is updated to use DITypeRef.
Move isUnsignedDIType and getOriginalTypeSize from DebugInfo.h to be static
helper functions in DwarfCompileUnit. We already have a static helper function
"isTypeSigned" in DwarfCompileUnit, and a pointer to DwarfDebug is added to
resolve the derived-from field. All three functions need to go across link
for derived-from fields, so we need to get hold of a type identifier map.
A pointer to DwarfDebug is also added to DbgVariable in order to resolve the
derived-from field.
Debug info verifier is updated to check a derived-from field is a TypeRef.
Verifier will not go across link for derived-from fields, in debug info finder,
we go across the link to add derived-from fields to types.
Function getDICompositeType is only used by dragonegg and since dragonegg does
not generate identifier for types, we use an empty map to resolve the
derived-from field.
When printing a derived-from field, we use DITypeRef::getName to either return
the type identifier or getName of the DIType.
A paired commit at clang is required due to changes to DIBuilder.
llvm-svn: 191800
and it is shared across CUs.
We add a few maps in DwarfDebug to map MDNodes for the type system to the
corresponding DIEs: MDTypeNodeToDieMap, MDSPNodeToDieMap, and
MDStaticMemberNodeToDieMap. These DIEs can be shared across CUs, that is why we
keep the maps in DwarfDebug instead of CompileUnit.
Sometimes, when we try to add an attribute to a DIE, the DIE is not yet added
to its owner yet, so we don't know whether we should use ref_addr or ref4.
We create a worklist that will be processed during finalization to add
attributes with the correct form (ref_addr or ref4).
We add addDIEEntry to DwarfDebug to be a wrapper around DIE->addValue. It checks
whether we know the correct form, if not, we update the worklist
(DIEEntryWorklist).
A testing case is added to show that we only create a single DIE for a type
MDNode and we use ref_addr to refer to the type DIE.
llvm-svn: 191792
For targets that have instruction itineraries this means no change. Targets
that move over to the new schedule model will use be able the new schedule
module for instruction latencies in the if-converter (the logic is such that if
there is no itineary we will use the new sched model for the latencies).
Before, we queried "TTI->getInstructionLatency()" for the instruction latency
and the extra prediction cost. Now, we query the TargetSchedule abstraction for
the instruction latency and TargetInstrInfo for the extra predictation cost. The
TargetSchedule abstraction will internally call "TTI->getInstructionLatency" if
an itinerary exists, otherwise it will use the new schedule model.
ATTENTION: Out of tree targets!
(I will also send out an email later to LLVMDev)
This means, if your target implements
unsigned getInstrLatency(const InstrItineraryData *ItinData,
const MachineInstr *MI,
unsigned *PredCost);
and returns a value for "PredCost", you now also need to implement
unsigned getPredictationCost(const MachineInstr *MI);
(if your target uses the IfConversion.cpp pass)
radar://15077010
llvm-svn: 191671
SelectionDAG will now attempt to inverse an illegal conditon in order to
find a legal one and if that doesn't work, it will attempt to swap the
operands using the inverted condition.
There are no new test cases for this, but a nubmer of the existing R600
tests hit this path.
llvm-svn: 191602
This is useful for targets like R600, which only support GT, GE, NE, and EQ
condition codes as it removes the need to handle unsupported condition
codes in target specific code.
There are no tests with this commit, but R600 has been updated to take
advantage of this new feature, so its existing selectcc tests are now
testing the swapped operands path.
llvm-svn: 191601
Interpreting the results of this function is not very intuitive, so I
cleaned it up to make it more clear whether or not a SETCC op was
legalized and how it was legalized (either by swapping LHS and RHS or
replacing with AND/OR).
This patch does change functionality in the LHS and RHS swapping case,
but unfortunately there are no in-tree tests for this. However, this
patch is a prerequisite for R600 to take advantage of the LHS and RHS
swapping, so tests will be added in subsequent commits.
llvm-svn: 191600
No functionality change. Future patches will add analysis which will be used
in other passes (PEI, StackSlot). The end goal is to support ssp-strong stack
layout rules.
WIP.
Differential Revision: http://llvm-reviews.chandlerc.com/D1521
llvm-svn: 191570
This change fixes the problem reported in pr17380 and re-add the dagcombine
transformation ensuring that the value types are always legal if the
transformation is triggered after Legalization took place.
Added the test case from pr17380.
llvm-svn: 191509
(shl (zext (shr A, X)), X) => (zext (shl (shr A, X), X)).
The rule only triggers when there are no other uses of the
zext to avoid materializing more instructions.
This helps the DAGCombiner understand that the shl/shr
sequence can then be converted into an and instruction.
llvm-svn: 191393
Ideally, the machinel model is added at the time the instructions are
defined. But many instructions in X86InstrSSE.td still need a model.
Without this workaround the scheduler asserts because x86 already has
itinerary classes for these instructions, indicating they should be
modeled by the scheduler. Since we use the new machine model for other
instructions, it expects a new machine model for these too.
llvm-svn: 191391
PEI inserts a save/restore sequence for the link register, according to the
information it gets from the MachineRegisterInfo.
MachineRegisterInfo is populated by the VirtRegMap pass.
This pass was not aware of noreturn calls and was registering the definitions of
these calls the same way as regular operations.
Modify VirtRegPass so that it does not set the isPhysRegUsed information for
registers only defined by noreturn calls.
The rational is that a noreturn call is the "last instruction" of the program
(if it returns the behavior is undefined), so everything that is defined by it
cannot be used and will not interfere with anything else. Therefore, it is
pointless to account for then.
llvm-svn: 191349
Patch by Ana Pazos.
1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.
llvm-svn: 191263
Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.
This fixes PR16979.
llvm-svn: 191260
a) Make sure we are emitting the correct section in our section labels
when we begin the module.
b) Make sure we are emitting the correct pubtypes section in the
presence of gnu pubtypes.
c) For C++ struct, union, class, and enumeration types are default
external.
llvm-svn: 191225
The size of common symbols is now tracked correctly, so they can be listed in the arange section without needing knowledge of other following symbols.
.comm (and .lcomm) do not indicate to the system assembler any particular section to use, so we have to treat them as having no section.
Test case update to account for this.
llvm-svn: 191210
This makes using array_pod_sort significantly safer. The implementation relies
on function pointer casting but that should be safe as we're dealing with void*
here.
llvm-svn: 191175
Previously, the DAGISel function WalkChainUsers was spotting that it
had entered already-selected territory by whether a node was a
MachineNode (amongst other things). Since it's fairly common practice
to insert MachineNodes during ISelLowering, this was not the correct
check.
Looking around, it seems that other nodes get their NodeId set to -1
upon selection, so this makes sure the same thing happens to all
MachineNodes and uses that characteristic to determine whether we
should stop looking for a loop during selection.
This should fix PR15840.
llvm-svn: 191165
