Add const to a bunch of Type* in DataLayout. NFC.

Almost all methods in DataLayout took mutable pointers but didn't need to.
These were only accessing constant methods of the types, or using the Ty

Add const to a bunch of Type* in DataLayout. NFC.

Almost all methods in DataLayout took mutable pointers but didn't need to.
These were only accessing constant methods of the types, or using the Type*
to key a map. Neither of these needs a mutable pointer.

llvm-svn: 243135

show more ...

fix formatting; NFC

llvm-svn: 242796

COFF: Let globals with private linkage reside in their own section

COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy thi

COFF: Let globals with private linkage reside in their own section

COFF COMDATs (for selection kinds other than 'select any') require at
least one non-section symbol in the symbol table.
Satisfy this by morally enhancing the linkage from private to internal.

Differential Revision: http://reviews.llvm.org/D8394

llvm-svn: 232570

show more ...

Teach DataLayout to infer a plausible alignment for things even when nothing is specified by the user.

llvm-svn: 231613

Make DataLayout Non-Optional in the Module

Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no

Make DataLayout Non-Optional in the Module

Summary:
DataLayout keeps the string used for its creation.

As a side effect it is no longer needed in the Module.
This is "almost" NFC, the string is no longer
canonicalized, you can't rely on two "equals" DataLayout
having the same string returned by getStringRepresentation().

Get rid of DataLayoutPass: the DataLayout is in the Module

The DataLayout is "per-module", let's enforce this by not
duplicating it more than necessary.
One more step toward non-optionality of the DataLayout in the
module.

Make DataLayout Non-Optional in the Module

Module->getDataLayout() will never returns nullptr anymore.

Reviewers: echristo

Subscribers: resistor, llvm-commits, jholewinski

Differential Revision: http://reviews.llvm.org/D7992

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 231270

show more ...

Teach DataLayout that alignments on basic types must be powers of two.

Fixes assertion failures/crashes on bad datalayout specifications.

llvm-svn: 230940

Teach DataLayout that ABI alignments for non-aggregate types must be non-zero.

This manifested as assertions and/or crashes in later phases of optimization,
depending on the build configuration.

ll

Teach DataLayout that ABI alignments for non-aggregate types must be non-zero.

This manifested as assertions and/or crashes in later phases of optimization,
depending on the build configuration.

llvm-svn: 230939

show more ...

Teach DataLayout that pointer ABI and preferred alignments are required to be powers of two.

Previously this resulted in asserts and/or crashes (depending on build configuration) at various phases i

Teach DataLayout that pointer ABI and preferred alignments are required to be powers of two.

Previously this resulted in asserts and/or crashes (depending on build configuration) at various phases in the optimizer.

llvm-svn: 230938

show more ...

Teach DataLayout that zero-byte pointer sizes don't make sense.

Previously this would result in assertion failures or simply crashes
at various points in the optimizer when trying to create types of

Teach DataLayout that zero-byte pointer sizes don't make sense.

Previously this would result in assertion failures or simply crashes
at various points in the optimizer when trying to create types of zero
bit width.

llvm-svn: 230936

show more ...

DataLayout: Validate that the pref alignment is at least the ABI align

llvm-svn: 229355

DataLayout: Report when the datalayout type alignment/width is too large

llvm-svn: 229354

DataLayout: Report when the preferred alignment is less than the ABI

llvm-svn: 228819

DataLayout: Provide nicer diagnostics for malformed strings

llvm-svn: 223911

DataLayout: Be more verbose when diagnosing problems in pointer specs

llvm-svn: 223903

DataLayout: Move asserts over to report_fatal_error

As indicated by the tests, it is possible to feed the AsmParser an
invalid datalayout string. We should verify the result of parsing this
string

DataLayout: Move asserts over to report_fatal_error

As indicated by the tests, it is possible to feed the AsmParser an
invalid datalayout string. We should verify the result of parsing this
string regardless of whether or not we have assertions enabled.

llvm-svn: 223898

show more ...

Switch the default DataLayout to be little endian, and make the variable
be BigEndian so the default can continue to be zero-initialized.

This is one of the prerequisites to making DataLayout a cons

Switch the default DataLayout to be little endian, and make the variable
be BigEndian so the default can continue to be zero-initialized.

This is one of the prerequisites to making DataLayout a constant and
always available part of every module.

llvm-svn: 220193

show more ...

IR: Replace DataLayout::RoundUpAlignment with RoundUpToAlignment

No functional change intended, just cleaning up some code.

llvm-svn: 220187

Use cast<> instead of unchecked dyn_cast<>

llvm-svn: 218085

Add doInitialization/doFinalization to DataLayoutPass.

With this a DataLayoutPass can be reused for multiple modules.

Once we have doInitialization/doFinalization, it doesn't seem necessary to pass

Add doInitialization/doFinalization to DataLayoutPass.

With this a DataLayoutPass can be reused for multiple modules.

Once we have doInitialization/doFinalization, it doesn't seem necessary to pass
a Module to the constructor.

Overall this change seems in line with the idea of making DataLayout a required
part of Module. With it the only way of having a DataLayout used is to add it
to the Module.

llvm-svn: 217548

show more ...

Revert "Introduce a string_ostream string builder facilty"

Temporarily back out commits r211749, r211752 and r211754.

llvm-svn: 211814

Introduce a string_ostream string builder facilty

string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.

small_string_ostream<by

Introduce a string_ostream string builder facilty

string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.

small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.

This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.

The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.

llvm-svn: 211749

show more ...

Use pointer size function where only a pointer is expected

llvm-svn: 207023

Fix DataLayout::operator==().

Patch by Maks Naumov!

llvm-svn: 206911

[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr.

llvm-svn: 205831

ARM: update subtarget information for Windows on ARM

Update the subtarget information for Windows on ARM. This enables using the MC
layer to target Windows on ARM.

llvm-svn: 205459