| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
common transformations. This includes updating repairIntervalsInRange() to
handle more cases.
llvm-svn: 175604
|
|
|
|
|
|
|
| |
correct value is needed in every iteration of the loop for updating
LiveIntervals.
llvm-svn: 175603
|
|
|
|
| |
llvm-svn: 175602
|
|
|
|
|
|
|
|
|
|
| |
and removing instructions. The implementation seems more complicated than it
needs to be, but I couldn't find something simpler that dealt with all of the
corner cases.
Also add a call to repairIndexesInRange() from repairIntervalsInRange().
llvm-svn: 175601
|
|
|
|
| |
llvm-svn: 175600
|
|
|
|
|
|
|
| |
assertions in the register allocator when running 'make check' without
LiveVariables.
llvm-svn: 175599
|
|
|
|
|
|
|
| |
after the two-address pass. The remaining problems in 'make check' are occurring
later.
llvm-svn: 175598
|
|
|
|
| |
llvm-svn: 175597
|
|
|
|
| |
llvm-svn: 175596
|
|
|
|
|
|
| |
Code review feedback on r175580 from Jordan Rose.
llvm-svn: 175595
|
|
|
|
|
|
| |
See r175462 for another example/more details.
llvm-svn: 175594
|
|
|
|
|
|
|
|
| |
SltCCRxRy16, SltiCCRxImmX16, SltiuCCRxImmX16, SltuCCRxRy16
$T8 shows up as register $24 when emitted from C++ code so we had
to change some tests that were already there for this functionality.
llvm-svn: 175593
|
|
|
|
| |
llvm-svn: 175592
|
|
|
|
| |
llvm-svn: 175591
|
|
|
|
| |
llvm-svn: 175590
|
|
|
|
| |
llvm-svn: 175589
|
|
|
|
|
|
| |
<rdar://problem/11540697>
llvm-svn: 175588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
|
|
|
| |
llvm-svn: 175586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MacroInfo class
for the data specific to a macro definition (e.g. what the tokens are), and
MacroDirective class which encapsulates the changes to the "macro namespace"
(e.g. the location where the macro name became active, the location where it was undefined, etc.)
(A MacroDirective always points to a MacroInfo object.)
Usually a macro definition (MacroInfo) is where a macro name becomes active (MacroDirective) but
splitting the concepts allows us to better model the effect of modules to the macro namespace
(also as a bonus it allows better modeling of push_macro/pop_macro #pragmas).
Modules can have their own macro history, separate from the local (current translation unit)
macro history; MacroDirectives will be used to model the macro history (changes to macro namespace).
For example, if "@import A;" imports macro FOO, there will be a new local MacroDirective created
to indicate that "FOO" became active at the import location. Module "A" itself will contain another
MacroDirective in its macro history (at the point of the definition of FOO) and both MacroDirectives
will point to the same MacroInfo object.
Introducing the separation of macro concepts is the first part towards better modeling of module macros.
llvm-svn: 175585
|
|
|
|
| |
llvm-svn: 175584
|
|
|
|
| |
llvm-svn: 175583
|
|
|
|
|
|
|
|
|
|
|
| |
RegionStoreManager::getInterestingValues() returns a pointer to a
std::vector that lives inside a DenseMap, which is constructed on demand.
However, constructing one such value can lead to constructing another
value, which will invalidate the reference created earlier.
Fixed by delaying the new entry creation until the function returns.
llvm-svn: 175582
|
|
|
|
| |
llvm-svn: 175581
|
|
|
|
|
|
|
|
|
| |
This generalizes Optional to require less from the T type by using aligned
storage for backing & placement new/deleting the T into it when necessary.
Also includes unit tests.
llvm-svn: 175580
|
|
|
|
|
|
|
| |
require call cpp file anyway, so we wouldn't gain anything by keeping them
inline.
llvm-svn: 175579
|
|
|
|
| |
llvm-svn: 175578
|
|
|
|
|
|
| |
declarations that set the attribute groups, so we must do it on our own.
llvm-svn: 175577
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MS-style inline assembly.
This is a follow-on to r175334. Forcing a FP to be emitted doesn't ensure it
will be used. Therefore, force the base pointer as well. We now treat MS
inline assembly in the same way we treat functions with dynamic stack
realignment and VLAs. This guarantees the BP will be used to reference
parameters and locals.
rdar://13218191
llvm-svn: 175576
|
|
|
|
|
|
|
|
| |
attributes yet, so just issue the appropriate diagnostics. Also generalize the
fixit for attributes-in-the-wrong-place code and reuse it here, if attributes
are placed after the access-specifier or 'virtual' in a base specifier.
llvm-svn: 175575
|
|
|
|
|
|
| |
its static value
llvm-svn: 175574
|
|
|
|
|
|
|
|
| |
select frame 0.
<rdar://problem/13093321>
llvm-svn: 175573
|
|
|
|
| |
llvm-svn: 175572
|
|
|
|
|
|
|
| |
which uses it. This is not ideal, but it ought to at least restore the
behavior to what it was before.
llvm-svn: 175571
|
|
|
|
|
|
|
|
|
|
| |
Be more user-friendly about not having scripting enabled:
a) if Python was built-out then tell people about it explicitly
b) if we are told to use none as a scripting language, then tell people about that too
This should limit the cases where the semi-cryptic error message "there is no embedded script interpreter in this mode." actually shows
llvm-svn: 175570
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (o32 abi) specific e_header setting.
EF_MIPS_ABI_O32 needs to be set in the
ELF header flags for o32 abi output.
Contributer: Reed Kotler
llvm-svn: 175569
|
|
|
|
| |
llvm-svn: 175568
|
|
|
|
| |
llvm-svn: 175567
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (Mips16) specific e_header setting.
EF_MIPS_ARCH_ASE_M16 needs to be set in the
ELF header flags for Mips16.
Contributer: Reed Kotler
llvm-svn: 175566
|
|
|
|
| |
llvm-svn: 175565
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Mips (MicroMips) specific STO handling .
The st_other field settig for STO_MIPS_MICROMIPS
Contributer: Zoran Jovanovic
llvm-svn: 175564
|
|
|
|
|
|
| |
we want to report that the ValueObject is dynamic since synthetic values are supposed to be just their parent with different children
llvm-svn: 175563
|
|
|
|
| |
llvm-svn: 175562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
excluding visibility bits.
Generic STO handling at the Target level.
The st_other field of the ELF symbol table is one
byte in size. The first 2 bytes are used for generic
visibility and are currently handled by llvm.
The other six bits are processor specific and need
to be set at the target level.
A couple of notes:
The new static methods for accessing and setting the "other"
flags in include/llvm/MC/MCELF.h match the style guide
and not the other methods in the file. I don't like the
inconsistency, but feel I should follow the prescribed
lowerUpper() convention.
STO_ value definitions are not specified in gnu land as
consistently as the STT_ and STB_ fields. Probably because
the latter were defined in a standards doc and the former
defined partially in code. I have stuck with the full byte
definition of the flags.
Contributer: Zoran Jovanovic
llvm-svn: 175561
|
|
|
|
| |
llvm-svn: 175560
|
|
|
|
| |
llvm-svn: 175559
|
|
|
|
| |
llvm-svn: 175558
|
|
|
|
| |
llvm-svn: 175557
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a base object is at a 0 offset, RegionStoreManager may find a lazy
binding for the entire object, then try to attach a FieldRegion or
grandparent CXXBaseObjectRegion on top of that (skipping the intermediate
region). We now preserve as many layers of base object regions necessary
to make the types match.
<rdar://problem/13239840>
llvm-svn: 175556
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In my previous commit:
"Merge a f32 bitcast of a v2i32 extractelt
A vectorized sitfp on doubles will get scalarized to a sequence of an
extract_element of <2 x i32>, a bitcast to f32 and a sitofp.
Due to the the extract_element, and the bitcast we will uneccessarily generate
moves between scalar and vector registers."
I added a pattern containing a copy_to_regclass. The copy_to_regclass is
actually not needed.
radar://13191881
llvm-svn: 175555
|